ast@cs.vu.nl (Andy Tanenbaum) (10/30/89)
Here is the proposed "official" MINIX file system layout as of 1.4b.
It is not entirely academic, because I was having a lot of trouble with
<minix/*.h> etc. Having two copies, one in /usr/include and one in
../h became unmanageable. They couldn't be links because I have them
on different disks. I have added /usr/include/blocksize.h, which is
all that most programs wanted anyway, and changed the other programs like
ls and diskcheck to #include "/usr/src/fs/const.h". There are only a few
such programs and they are all programs that have to know about the
inner workings of the system. Ordinary user programs are not affected.
Andy Tanenbaum (ast@cs.vu.nl)
/ root directory
/bin heavily used binaries
/dev special files for the I/O devices
/etc /etc/passwd, /etc/rc, etc.
/lib heavily used libraries
/tmp tmp files
/usr users
/usr/adm used by 'at' etc
/usr/ast sample home dir
/usr/bin system binaries (superset of /bin)
/usr/doc documentation lives here
/usr/etc misc. (superset of /etc)
/usr/lib compiler, libc.a, etc. (superset of /lib)
/usr/man man pages live here
/usr/tmp alternative tmp dir
/usr/include ANSI/POSIX header files
/usr/include/sys <sys/types.h> etc.
/usr/spool spooling dir
/usr/spool/at 'at' program uses this
/usr/spool/mail holds user mailboxes
/usr/spool/uucp uucp spooling directory
/usr/spool/lpd line printer daemon spooling dir
/usr/src the entire source tree
/usr/src/amoeba amoeba tree
/usr/src/commands sources of the utilities
/usr/src/compiler C compiler source (if you have it)
/usr/src/fs file system source code
/usr/src/h operating system specific headers
/usr/src/kernel kernel source code
/usr/src/mm memory manager source code
/usr/src/pascal Pascal compiler source (if you have it)
/usr/src/test test programs sources and binaries
/usr/src/tools tools for building MINIX
/usr/src/lib library sources
/usr/src/lib/IBM_PC IBM specific sources (assembler)
/usr/src/lib/M68000 Motorola 68000 sources (assembler)maart@cs.vu.nl (Maarten Litmaath) (10/31/89)
ast@cs.vu.nl (Andy Tanenbaum) writes:
\... I was having a lot of trouble with
\<minix/*.h> etc. Having two copies, one in /usr/include and one in
\../h became unmanageable. They couldn't be links because I have them
\on different disks. [...]
I think there exists a neat solution to this problem...
(It was 1 of the Operating Systems class assignments, about 2 years ago!)
--
A symbolic link is a POINTER to a file, | Maarten Litmaath @ VU Amsterdam:
a hard link is the file system's GOTO. | maart@cs.vu.nl, mcsun!botter!maartstailey@iris613.gsfc.nasa.gov (Ken Stailey) (10/31/89)
In article <4381@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >Here is the proposed "official" MINIX file system layout as of 1.4b. > /usr/src/lib library sources > /usr/src/lib/IBM_PC IBM specific sources (assembler) > /usr/src/lib/M68000 Motorola 68000 sources (assembler) I find hugh directories unmanagable. I broke apart /usr/src/lib in the version 7 fashion: /usr/src/libc/stdio stdio, printf et. al. /usr/src/libc/sys system call interface routines read(), fork() /usr/src/libc/crt c runtime support _xxx.s /usr/src/libc/gen malloc(), regexp(), strcpy() I was pleased with the balanced load that this approach provided. INET stailey@iris613.gsfc.nasa.gov UUCP {backbone}!dftsrv!iris613!stailey
linas@hpuarca.HP.COM (Linas Petras) (11/06/89)
I second the motion for splitting the library source directory. It would get rid of the problem of not being able to "ls" the directory after you have compiled all the library source and I belive, make the library more manageable. Linas Petras Hewlett Packard Aust Ltd Australasian Response Center 31 Joseph St, Blackburn. UUCP: ...!hplabs!hpcea!hpausla!hpuarca!linas Victoria 3130., Australia ACSNET: linas@hpuarca.hp.oz [ The comments, views, opinions and requests expressed in this note are my own] [ and have nothing to do with my employeer, nor do I know why I am making them] [ as I have nothing to say :-) ]