Re: Hurd FS hierarchy (was Re: LD_LIBRARY_PATH troubles)

[Marcus Brinkmann]

On Sun, May 12, 2002 at 01:09:08PM -0400, Richard Kreuter wrote:
> > > /hurd 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.
> > 
> > > The following servers, or symbolic links to servers, are required in
> > > /hurd.
> > 
> > > auth[.static]  The standard authentication server.
> > > exec[.static]  The standard execution server.
> > > init[.static]  The standard initialization and state maintaining server.
> > > proc[.static]  The standard process server.
> > 
> > Is there a valid reason why these translators should be static? 
> 
>   Perhaps not.  However, consider this argument: (1) the standard
> should allow/should not forbid any particular statically linked
> servers in /hurd,

Indeed.  Although if we are anal about it, we can specify that only
bootstrap filesystems (filesystems that can be used as a bootstrap
filesystem) are allowed to be statically linked.

> (2) statically linked servers in /hurd may be named
> foo.static, so if the only auth, exec, init, proc servers in /hurd are
> statically linked, then they may be named auth.static, etc.  Seem
> sensible?

I don't know what the above [.static] really means.  In anyway, I am not
sure that the FHS should say anything about the content of /hurd at this
level of detail.  It should suffice to say that /hurd contains executables
that can be used (primarly, only?) as Hurd translators.  It should not
forbid putting exectuables that can be used as Hurd translators into /bin,
btw.

I don't think it should list translators auth, proc etc...  the startup
procedure is defined by the bootstrap filesystem, and the technical details
can change.  A different, minimalistic bootstrap filesystem might prefer to
be the auth translator itself instead starting one.  A mini-Hurd system with
a multi-functional bootstrap filesystem would then violate the FHS.

>   Right.  Should we add something like
> 
> "In addition to the above, at least one file system translator must be
> found under /hurd, and at least one file system translator in /hurd
> must be statically linked, in order to boot the Hurd."
> 
> Comments?

Again, I don't see why the FHS should contain implementation details about
the current Hurd system, although this level of detail might be what the FHS
expects to define, so sorry if I am too restrictive.

However, please consider that the bootstrap filesystem (which is the only
file beside the kernel that needs to be linked statically) is loaded by
GRUB.  If you have ext2fs.static on a boot disk, CD Rom or network storage,
you don't need one in the filesystem at run time at all.

To repeat: Nothing requires a statically linked filesystem (or any
translator) after you have loaded and started the initial bootstrap filesystem,
which is done by GRUB and the kernel.  GRUB might be configured to take the
ext2fs.static from some network storage, and the root filesystem from
another storage, and then this root filesystem does not need to have any
*.static translator.

> > > /servers/startup     <What's this do?>
> > 
> > Never heard of /servers/startup.. Where did you get this from? (Can't
> > find anything in the archives)
> 
>   Thomas Bushnell told me to look through paths.h.  My source is old,
> though.  Is this faulty?

I think it doesn't exist, although it might in the future.  Definitely leave
it out for now.  It makes sense to specify those paths in the FHS (more
sense than to specify the content of /hurd/*), as those are indeed expected
rendevouz ports by the C library and Hurd programs.

Currently the only server ports used are:

CRASH, EXEC, PASSWORD, SOCKET/PF_LOCAL, SOCKET_PFINET

If we specify this in the standard, I hope we get to adapt this to the
reality when Hurd development changes.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de