Subject: DRAFT of File System document

From: Alan B Clegg <[email-masked]>
Date: Thu, 6 Feb 92 9:17:37 EST

Please let me know what you think of this [pro and con arguments are requested]

=====SNIP HERE=====
The following is being submitted by Alan Clegg [[email-masked]] as the
proposed standard for directory file structure under Linux.

Complete implementation of this file structure is completely voluntary,
and will not be enforced, but will be recommended.  This specification
is released as guidelines for people porting and writing software for
the Linux Operating System to allow easy software installation, upgrade,
and tailoring on already installed systems.

Root Directory:

	Files:
		{none defined by spec}

	Directories:
		bin dev etc lib mnt usr
	
	Rationale:
		The root directory should not be cluttered with files or
		directories, and should contain no user programs.

/bin Directory:

	Files:
		sh init mount umount dd cat ls fsck [?others?]
		[should ls be there if 'echo *' works?]

	Directories:
		{none defined by spec}

	Rationale:
		The /bin directory should contain programs that are vital
		to the restoration of other file systems in the case of 
		a corrupting crash.  No executable in /bin should require
		any other file system to be mounted to execute correctly.

/dev Directory:

	Files:
		{device files}

	Directories:
		{none define by spec}

	Rationale:
		Standard UNIX[tm] device files.  This directory should contain
		device entries for all devices that are supported in the
		standard kernel, even if the hardware device does not exist
		on the system. [comments?]

/etc Directory:

	Files:
		mtab passwd rc ttytab {and as needed}

	Directories:
		{none defined by spec}

	Rationale:
		Standard location of files required during system boot.  Files
		in this directory are usually system specific.  Most will
		require human intervention during system upgrade.

/lib Directory:

	Files:
		{libraries required for system initialization}

	Directories:
		{none defined by spec}

	Rationale:
		To keep the size of the root partition small (if separate from
		/usr), the files in this directory should only be ones required
		by files in the root partition.

/mnt Directory:
	
	Files:
		NONE

	Directories:
		NONE

	Rationale:
		Standard mount point for external (transient) file systems.
		Must be available for sub-system installation.  Should remain
		as an empty directory.

/tmp Directory:
	
	Files:
		NONE
	
	Directories:
		NONE

	Rationale:
		Temporary file space available for general program use.  May
		become a mounted partition upon system boot.  [Minimum size?]

/usr Directory:

	Files:
		{none defined by spec}

	Directories:
		adm bin spool local lib etc man include src tmp linux users

	Rationale:
		/usr is the mount point for the second major (after root)
		hierarchy of file structure and is discussed in the next
		section.

/usr/adm Directory:

	Files:
		{none defined in spec}

	Directories:
		{none defined in spec}

	Rationale:
		Location of log files and accounting information.

/usr/bin Directory:

	Files:
		{all files from standard distribution not contined in /bin}

	Directories:
		{none defined in spec}

	Rationale:
		contains 'drop-in' executables that are considered to be
		standard to the UNIX system.  These files should NOT be
		Linux specific, but should have the same function as their
		UNIX equivalents.

/usr/etc Directory:
	
	Files:
		{none defined in spec}

	Directories:
		{none defined in spec}

	Rationale:
		contains configuration files for any files in /usr/bin. helps
		to keep /etc clean and small.

/usr/spool Directory:

	Files:
		{none defined in spec}

	Directories:
		uucp mail

	Rationale:
		containes spool files for mail, printing, uucp transfer, etc.
		May be a mount point for another volume.

/usr/local Directory:

	Files:
		{none defined in spec}
	
	Directories:
		bin lib etc man src

	Rationale:
		contains files local to the specific system.  will not be
		modified by upgrade process. 

/usr/lib Directory:

	Files:
		libc.a crt0.s {and as needed}

	Directories:
		{none defined in spec}

	Rationale:
		location for library files required for multi-user system
		operation.  This is the directory where program libraries
		should reside.

/usr/man Directory:

	Files:
		NONE
	
	Directories:
		man1 man2 man3 man4 man5 man6 man7 man8

	Rationale:
		Contains manual pages for programs that are standard with
		Linux.

/usr/include Directory:

	Files:
		{programmers include files}

	Directories:
		{as needed}

	Rationale:
		Standard place for system include files.

/usr/src Directory:
	
	Files:
		NONE
	
	Directories:
		bin lib linux usr.bin usr.linux

	Rationale:
		Contains source code for all applications in the release.
		/usr/src/linux contains directories required for kernel builds.

/usr/tmp Directory:

	Files:
		NONE

	Directories:
		NONE

	Rationale:
		Used as additional scratch space for programs.  If /tmp is
		a mounted file system, /usr/tmp may be a symbolic link to
		/tmp.

/usr/linux Directory:

	Files:
		NONE

	Directories:
		bin lib etc

	Rationale:
		Contains programs that are "linux specific" and programs that
		semantics are different from the standard UNIX usage.

/usr/users Directory:	[Probably /home]

	Files:
		NONE
	
	Directories:
		{one for each user, except root}

	Rationale:
		Users home directories.  [Root's home directory should be
		on the root partition somewhere.]

=====SNIP HERE=====

Please feel free to comment on these ideas, and let me know what you think.
-- 
[email-masked]				Alan Clegg - Network Programmer
KD4JML (just my luck!)			MCNC -- Center for Communications

---

From: Dirk Hohndel <[email-masked]>
Date: Thu, 6 Feb 92 16:13:36 MET

Alan B Clegg writes
> Root Directory:

ok

> 		sh init mount umount dd cat ls fsck [?others?]

programs to set up / check networking (a la ifconfig)

> 		[should ls be there if 'echo *' works?]

maybe yes, some options of ls might be useful in single user mode

> 		any other file system to be mounted to execute correctly.

Good point

> 		device entries for all devices that are supported in the
                                   ^^^
> 		on the system. [comments?]

Why ? a minimal configuration doesn't need devices for tape, scanner, 16 COMs
8 LPTs 15 disks and so on

> 		mtab passwd rc ttytab {and as needed}

group hosts (!) printcap

> /lib Directory:

ok

> /mnt Directory:

ok

> /tmp Directory:

ok

> 		{none defined in spec}

adduser, rmuser and related stuff ?
> 		Location of log files and accounting information.
Maybe programms of administrative charakter not needed in single user mode ?

> 		Linux specific, but should have the same function as their
maybe gcc should be HERE !

> /usr/etc Directory:

ok

> /usr/spool Directory:

ok

> 		modified by upgrade process. 

does that meen that in our standard release this directory is empty ?

> 		operation.  This is the directory where program libraries

what about shared libs ?

> /usr/man Directory:

ok

> /usr/include Directory:

ok

> 		/usr/src/linux contains directories required for kernel builds.

good idea

> /usr/tmp Directory:

ok

> /usr/linux Directory:

ok

> /usr/users Directory:	[Probably /home]

this should not be ruled, because we should force (urge, beg,...) people to
leave their habbit. I think someone is used to /home/joe the otherone to
/u/joe or anything else

All in all : accepted !!

Dirk

-- 
 Dirk Hohndel   				Lehrstuhl fuer Informatik I
 [email-masked]    	Universitaet Wuerzburg
 Tel. 0931 / 888-5057				Am Hubland	
 Fax. 0931 / 888-4600				D-8700 Wuerzburg

---

From: Alan B Clegg <[email-masked]>
Date: Thu, 6 Feb 92 10:33:52 EST

> programs to set up / check networking (a la ifconfig)
Yes, I could not think of all the possibilities, just be sure that they fit
in with the Rationale... 8-)

> maybe yes, some options of ls might be useful in single user mode
Agreed.

> 8 LPTs 15 disks and so on

Right.  Probably don't need all of 'em..

> adduser, rmuser and related stuff ?
Yup.. but gotta wait till someone ports them.. 8-)

> Maybe programms of administrative charakter not needed in single user mode ?

Well, yes-and-no.  Perhaps these files should really reside in /usr/bin?
This is where the call gets hard to make.

> maybe gcc should be HERE !
Yes!

> does that meen that in our standard release this directory is empty ?

Yes.

> what about shared libs ?
Dunno.. where *DO* they live?  I would assume that /usr/lib is the right place.

> leave their habbit. I think someone is used to /home/joe the otherone to

None of these are rules, since I know that everyone is *VERY* opinionated.
I have taken the best arguments for each of the file systems and come up with
this.  It seems that it is very close to the BSD 4.3 structure (although I
don't have access to one of them to check it out). 

> All in all : accepted !!

Thanks,
-abc

---

From: Alan B Clegg <[email-masked]>
Date: Thu, 6 Feb 92 14:24:03 EST

EEEEEeeeeekkkk!

The list of files in each directory was a *SAMPLE*.  I was not meaning to list
every single file... that will come later.  

I must say, so-far, the comments have been very positive.  Thanks!

-abc

---

From: [email-masked] ("Mark W. Eichin")
Date: Thu, 6 Feb 92 14:22:12 -0500

Overall it looks good; I've got a few comments on specific sections...

>		to the restoration of other file systems in the case of 
	Add mknod to the list? if you lose some device (or change the
kernel in such a way that device numbers change) you're really going
to need it...

/dev Directory:
	Many Unix systems also put MAKEDEV in here - a shell script
which takes "common names" as arguments and creates the devices to
match (ie. MAKEDEV pty 8 will make the first 8 pty master/slave
pairs.) 

>		Standard location of files required during system boot.  Files
	I believe the convention here has evolved to *configuration*
files need at boot time; the rc files are a special case, since they
are config files but they happen to be executable... Otherwise, there
are really no programs that belong in etc.

>		a mounted file system, /usr/tmp may be a symbolic link to
	On most Unix systems I'm familiar with, there is an important
semantic distinction between /tmp and /usr/tmp which precludes the use
of a symlink: /tmp is cleaned at boot time, /usr/tmp isn't. Thus, many
programs keep "autosave" files in /usr/tmp (there are very good
reasons not to keep them in the same directory as the original, for
example if the original is a *slow* (ie. networked) or nearly full
file system, you take a real hit when doing autosaves -- but you want
to do them as often as you can get away with...)

>		semantics are different from the standard UNIX usage.
	This sounds bad for the same reason that "/usr/ucb" is -- that
there isn't anything truly "linux specific". Can you name things that
really should go here? 
	As for "different" programs, that'll just be a reason for me
*not* to have /usr/linux/bin in my path...

/usr/local Directory:
	Well, I suppose this is the right thing to do at this level,
but let me tell a few stories from my experiences...
	1) At Cygnus Support, internally we have three categories of
installed packages: "latest", "vintage", and "unsupported". Latest and
vintage typically have overlapping contents; latest is whatever got
most recently compiled, whereas vintage is the "long term stable"
version. "unsupported" means anything we're not paid to support (for
example, X11 ends up here, as unsupported/X11/{bin,lib...}; most
things off the net end up here.) We specifically don't *have* a
/usr/local because so many things come off the net with /usr/local
hard coded, and we have to find those paths ourselves (our customers
to install our packages under /usr/cygnus - we can't preempt their
/usr/local.)
	2) At MIT (Project Athena), *everything* is out on the net (it
is a pain to update a full software load on 1K workstations, so only
the base OS is on them.) There are different size packages, from the
full Athena setup (which gets put under one mountpoint, so that
symlinks from the workstation local disk get "filled in") to smaller
"lockers", some of which have groups of programs (such as the "gnu"
locker), and some of which have single programs (such as the lockers
for saber, calendar, S...). For consistency, lockers all go under the
/mit directory (which is, granted, very provincial :-) however, there
is an "add" alias which automatically adds the locker's bin directory
to the user's path. This leads to some extensive paths; mine only has
17 elements in it, but I haven't been using many packages this
session. The path length is not usually a major performance problem,
at least for executable searches, partially because of the hashed
directory cache in the shell; "man" sometimes gets slow, particularly
when it *doesn't* find the name because you misspelled it and has to
search 10 directories per path entry for the rest. [Summary: don't be
afraid of long paths.] /usr/local just isn't general enough to cover
this, though it gets used occasionally on "private" workstations.
	As for the base operating system, some work was done on
minimizing the contents of the root (so that fast local disk could be
more profitably used as swap, tmp, and AFS cache space) so some
interesting distinctions were made (and *lots* of symlinks...) For
example, /bin contained things that had to be on the root; /usr/bin
contained things that didn't. (Recently, /usr/athena/{bin,lib,etc}
were also added to cover things that Athena was specifically
responsible for rather than scattering them elsewhere in the
filesystem.) 

	Another story: if you've kept up with Plan 9 from Bell Labs,
their shell ("rc" - and I mean the Plan 9 version, *not* the clone
available on the net) *doesn't* support a PATH. All executables are in
/bin; you just "mount" other directories "after" /bin, so that the
filesystem shows /bin as one (very long) directory. This is going
somewhat in the other direction (and is not very practical to us, as
Linux doesn't support union directories [nor does any operating system
other than Plan 9 as far as I know]) but has some merit to it. (These
"mounts" are entirely per process, not system wide, though your child
processes inherit them.)

				_Mark_ <[email-masked]> N1DPU
				MIT Student Information Processing Board
				Cygnus Support <[email-masked]>

---

From: David Engel <[email-masked]>
Date: Thu, 6 Feb 92 13:52:10 CST

> 		{none defined by spec}

For those who boot from the hard disk (using shoelace or whatever), we
probably want to put the kernel itself here.  We probably also want to
give it a "standard" name so programs like ps can get information from
it when /dev/kmem is implemented.

David

---

From: [email-masked] (Thomas David Rivers)
Date: 7 Feb 92 16:40:16 EST (Fri)

Shared libraries live in /shlib on ISC; and in /lib on HP/UX.