[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Clarification about section 3.1 (The Root Filesystem, Purpose)
From: |
Richard Kreuter |
Subject: |
Re: Clarification about section 3.1 (The Root Filesystem, Purpose) |
Date: |
Sat, 12 Oct 2002 12:00:16 -0500 |
User-agent: |
Mutt/1.4i |
On Sat, Oct 12, 2002 at 05:18:45PM +0200, Alfred M. Szmidt wrote:
> Richard Kreuter <kreuter@anduril.rutgers.edu> writes:
> > I've got a slightly newer draft, nearly properly groff formatted,
> > but I've no place to post it online right now. Should I submit it
> > here?
>
> Sure, that way we can comment on it via mail.
Okay, the patches follow. The first patch contains additions proposed
to the FHS body, the second the GNU/Hurd annex. Note: I have not yet
included the proposal to move /lib/modules to the 'Linux specific
annex'.
Also, the formatting was my first stab at groff, and I don't know how
to unindent after a .VL, so the GNU/Hurd annex is improperly formatted
in any section that contains text after the end of such a list.
*** draft.mm.orig Fri Oct 11 22:22:57 2002
--- draft.mm Sat Oct 12 11:51:15 2002
***************
*** 597,602 ****
--- 597,617 ----
the firmware. This may result in restrictions with respect to usable
filenames within \f(CW/boot\fP (only for affected systems).
.FE
+ .P
+ As an exception, the bootloader Grub may place its configuration file
+ under \f(CW/boot\fP.
+ .StartRationale
+ Grub reads its configuration and second-stage loader files at
+ boot-time, and these must reside in the same filesystem for Grub to
+ work (in Grub's current implementation, at least). Moreover, Grub is
+ intended to be able to boot directly diverse operating systems, so
+ that Grub's configuration file may be the configuration file of the
+ bootloader for several operating systems on a dual-booting machine.
+ Consequently, it may be necessary for Grub to store its configuration
+ along with its static files in the same filesystem, for example, in
+ case one operating system can't access another's native filesystem
+ type.
+ .EndRationale
.\" -------------------------------------------------------------------
.H 2 "/dev : Device files"
.P
***************
*** 1854,1860 ****
.P
.H 3 "Purpose"
This directory holds system crash dumps. As of the date of this release
! of the standard, system crash dumps were not supported under Linux.
.\" -------------------------------------------------------------------
.H 2 "/var/games : Variable game data (optional)"
.P
--- 1869,1876 ----
.P
.H 3 "Purpose"
This directory holds system crash dumps. As of the date of this release
! of the standard, system crash dumps were not supported under Linux, but
! may be supported by other systems which may comply with \*(Fs.
.\" -------------------------------------------------------------------
.H 2 "/var/games : Variable game data (optional)"
.P
*** draft.mm.orig Fri Oct 11 22:22:57 2002
--- draft.mm Sat Oct 12 11:54:23 2002
***************
*** 2388,2393 ****
--- 2388,2610 ----
.P
This directory contains the variable data for the \f(CWcron\fP and
\f(CWat\fP programs.
+ .\" -------------------------------------------------------------------
+ .H 2 "GNU/Hurd"
+ .P
+ This is the annex for the GNU/Hurd operating system. The GNU/Hurd
+ system is differs from other \*(Ux-like operating systems both in
+ the way it treats the filesystem namespace and in the power it provides
+ to system users. The filesystem namespace is very flexible, you can do
+ anything with it what you want. That's why it is reasonable to specify
+ where you should find directories and files, but not the way those
+ directories and files should get there.
+ .P
+ System users are able to extend system functionality in ways
+ traditionally prohibited, so that tools that are only useful to
+ administrators on other systems can be useful to standard users on
+ GNU/Hurd; consequently, these tools ought to be available in locations
+ that may differ from their locations on other systems.
+ .P
+ As a rule, distributors who wish to maintain compatibility between
+ their distributions of GNU/Hurd, GNU/Linux, or other systems may
+ maintain symbolic links to files whose locations on GNU/Hurd systems
+ differ from their locations on other systems. This accomodates
+ programs with "hard-coded" filenames. For example, files that should
+ be found under \f(CW/libexec\fP may be symbolic links, or may be the
+ targets of symbolic links located under \f(CW/sbin\fP, \f(CW/bin\fP,
+ and so forth.
+ .\" -------------------------------------------------------------------
+ .H 3 "/ : The Root directory"
+ .P
+ It is permitted to create a new subdirectory of the root directory by
+ the distribution creator or user.
+ .\" -------------------------------------------------------------------
+ .H 3 "/boot : Static files of the bootloader"
+ .P
+ If the following is not provided in the body of \*(Fs, then the
+ configuration file for the grub bootloader may be found under
+ \f(CW/boot\fP.
+ .\" -------------------------------------------------------------------
+ .H 3 "/bin : Essential user command binaries (for use by all users)"
+ .P
+ The following files, or symbolic links to files, used for system boot
+ and recovery, must be located in \f(CW/bin:\fP.
+ .VL 2
+ .TS
+ tab(@);
+ lfCW l.
+ settrans@Command to set/remove translators
+ showtrans@Translator setting information utility
+ fsysopts@File system option manipulator
+ .TE
+ .P
+ The following utilities may be omitted from \f(CW/bin\fP:
+ .VL 2
+ .LI "\f(CW{"
+ dmesg
+ mount
+ umount }\fP
+ .LE
+ .P
+ The GNU/Hurd system has been designed with a goal of providing users
+ with more power than they have traditionally been afforded on \*(Ux and
+ \*(Ux-compatible systems. As a result, several system binaries are
+ useful to normal users and should be found in \f(CW/bin\fP. The
+ following files, or symbolic links to files, must be in \f(CW/bin\fP if
+ the corresponding subsystem is installed:
+ .VL 2
+ .LI "\f(CW{"
+ fdisk
+ fsck
+ fsck.*
+ mkfs
+ mkfs.*
+ parted }\fP
+ .LE
+ .\" -------------------------------------------------------------------
+ .H 3 "/com : Shareable, variable data"
+ .P
+ The \f(CW/com\fP hierarchy contains files architecture-independent
+ data files which the programs modify while they run. Some of these
+ files have been placed in \f(CW/var\fP or \f(CW/usr\fP in the past; in
+ case a distributor wishes to maintain compatibility with systems that
+ expect to find these files in \f(CW/var\fP or \f(CW/usr\fP, symbolic
+ links may be used.
+ .StartRationale
+ Having recognized the distinction between shareable and non-shareable
+ mutable data files, the authors of the GNU Coding Standards intend
+ that all shareable mutable data files be found under a single
+ directory, to simplify management of shared file hierarchies among
+ systems.
+ .EndRationale
+ .\" -------------------------------------------------------------------
+ .H 3 "/hurd : The Hurd servers"
+ .P
+ \f(CW/hurd\fP contains the Hurd server binaries. Servers with .static
+ appended to their name must be statically linked servers, servers
+ without .static appended may be dynamically linked servers.
+ .\" -------------------------------------------------------------------
+ .H 3 "/libexec : Executables run only by other programs"
+ .P
+ The directory for installing executable programs to be run by other
+ programs, rather than by users.
+ .P
+ Note that some programs that are normally run only by other programs may
+ occasionaly be run by users under certain circumstances, such as
+ debugging. Nevertheless, such programs are to be found in
+ \f(CW/libexec\fP.
+ .P
+ The following are example programs that could be found in
+ \f(CW/libexec\fP, if they exist on a system:
+ .VL 2
+ .TS
+ tab(@);
+ lfCW l.
+ in.telnetd@Telnet protocol daemon
+ in.ftpd@Ftp protocol daemon
+ sendmail@Internet mail transport agent
+ .TE
+ .P
+ .StartRationale
+ A number of programs are intended to be run only by other programs.
+ These programs therefore don't belong in directories containing
+ commands for users.
+ .EndRationale
+ .\" -------------------------------------------------------------------
+ .H 3 "/sbin : System binaries"
+ .P
+ The following files, or symbolic links to files, may be found in
+ \f(CW/sbin\fP:
+ .VL 2
+ .TS
+ tab(@);
+ lfCW l.
+ devprobe@Hardware device detection utility
+ .TE
+ .P
+ .\" -------------------------------------------------------------------
+ .H 3 "/servers : Standard location where Hurd servers translate"
+ .P
+ This is the directory Hurd servers translate rendezvous filesystem
+ nodes in standard locations, so that other programs can easily find
+ them and use server-specific interfaces.
+ .P
+ The following files must be found in \f(CW/servers\fP:
+ .VL 2
+ .TS
+ tab(@);
+ lfCW l.
+ \f(CW/servers/crash\fP@The node where the crash server translates.
+ \f(CW/servers/exec\fP@The node where the exec sever translates.
+ \f(CW/servers/password\fP@The node where the password server translates.
+ \f(CW/servers/proc\fP@The node where the process server translates.
+ .TE
+ .P
+ In addition, all files with names of the form \f(CW/servers/socket/N\fP,
+ where \f(CWN\fP is a string of digits, are reserved as rendezvous points
+ for domain socket translators. Symbolic links to these files are also
+ permitted in the \f(CW/servers/socket\fP directory, as shown in the
+ example below.
+ .VL 2
+ .TS
+ tab(@);
+ lfCW l.
+ \f(CW/servers/socket/1\fP@The node where the pflocal server translates.
+ \f(CW/servers/socket/2\fP@The node where the pfinet server translates.
+ \f(CW/servers/socket/local\fP@A symbolic link to \f(CW/servers/socket/1\fP.
+ \f(CW/servers/socket/inet\fP@A symbolic link to \f(CW/servers/socket/2\fP.
+ .TE
+ .P
+ .\" -------------------------------------------------------------------
+ .H 3 "/usr : Secondary Hierarchy"
+ .P
+ In the GNU/Hurd system, \f(CW/usr\fP is a symbolic link to \f(CW.\fP
+ in the root directory. Thus the \f(CW/\fP and \f(CW/usr\fP
+ directories have the same name and names of files and directories
+ within them must not conflict.
+ .StartRationale
+ The GNU Hurd will have a special filesystem, called shadowfs, which
+ will be able to "merge" directories. Thus everything from different
+ sources will be able to be merged (both static and variable data) and
+ /usr isn't really needed. Instead of \f(CW/usr\fP, everything will be
+ found under \f(CW/\fP.
+ .EndRationale
+ .\" -------------------------------------------------------------------
+ .\".H 3 "/usr/share/info : The GNU Info system's primary directory"
+ .\".P
+ .\"This directory may exist as the primary GNU/Hurd Info system
+ .\"directory.
+ .\".P
+ .\" -------------------------------------------------------------------
+ .H 3 "/usr/share/man : Online manuals"
+ .P
+ This directory is optional on a GNU/Hurd system.
+ .P
+ .\" -------------------------------------------------------------------
+ .H 3 "/usr/X11R6 : X Window System, Version 11 Release 6"
+ .P
+ This directory should not be used. Instead the X Window System should
+ be placed in \f(CW/\fP.
+ .P
+ .\" -------------------------------------------------------------------
+ .H 3 "/var : Mutable, machine-specific data files"
+ .P
+ The \f(CW/var\fP hierarchy should normally not contain files that can be
+ shared among host systems. These files should instead be found in
+ \f(CW/com\fP.
+ .StartRationale
+ Having recognized the distinction between shareable and
+ non-shareable mutable data files, the authors of the GNU Coding
+ Standards intend that all unshareable mutable data files be found
+ under a single directory, to simplify management of shareable file
+ hierarchies among host systems.
+ .EndRationale
+ .\" -------------------------------------------------------------------
+ .H 3 "/var/spool/cron : cron and at jobs"
+ .P
+ This directory contains the variable data for the cron and at
+ programs.
+ .\" -------------------------------------------------------------------
.SK
.\" -------------------------------------------------------------------
.\" Trailing stuff
- Re: Clarification about section 3.1 (The Root Filesystem, Purpose), (continued)
- Re: Clarification about section 3.1 (The Root Filesystem, Purpose), Marcus Brinkmann, 2002/10/14
- Re: Clarification about section 3.1 (The Root Filesystem, Purpose), Niels Möller, 2002/10/14
- Re: Clarification about section 3.1 (The Root Filesystem, Purpose), Thomas Bushnell, BSG, 2002/10/14
- Directories or Libraries ?, Thomas Sippel - Dau, 2002/10/15
- Re: Clarification about section 3.1 (The Root Filesystem, Purpose), Thomas Bushnell, BSG, 2002/10/14
Re: Clarification about section 3.1 (The Root Filesystem, Purpose), Marcus Brinkmann, 2002/10/12
Re: Clarification about section 3.1 (The Root Filesystem, Purpose), Richard Kreuter, 2002/10/12