help-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Richard Kreuter
Subject: Re: Hurd FS hierarchy (was Re: LD_LIBRARY_PATH troubles)
Date: Sun, 12 May 2002 13:09:08 -0400
User-agent: Mutt/1.2.5i

On Sun, May 12, 2002 at 10:57:42AM +0200, Alfred M. Szmidt wrote:
> * Richard Kreuter writes:
> > 6.2.x  /hurd : The Hurd servers
> 
> > /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, (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?

> The only translator that I know should be static is the file system
> one.  What about a file system translator? The system is quite
> useless without it.

  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?

> > 6.2.x  /servers : Standard location where Hurd servers translate
> 
> > 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.
> 
> > /servers/crash         The node where the crash server translates.
> > /servers/exec      The node where the exec sever translates.
> > /servers/password  The node where the password server translates.
> > /servers/proc          The node where the process server translates.
> > /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?

/* Port rendezvous points are specified by symbols _SERVERS_FOO,
   the canonical pathname being /servers/foo.  */

#define _SERVERS                "/servers/"
#define _SERVERS_CRASH          _SERVERS "crash"
#define _SERVERS_EXEC           _SERVERS "exec"
#define _SERVERS_STARTUP        _SERVERS "startup"
#define _SERVERS_PROC           _SERVERS "proc"
#define _SERVERS_PASSWORD       _SERVERS "password"


> > In addition, all files with names of the form /servers/socket/N,
> > where N is a string of digits, are reserved for <somebody who knows
> > the score to finish this sentence>.
> 
> /include/hurd/paths.h:
> /* Directory containing naming points for socket servers.
>    Entries are named by the string representing the domain number
>    in simple decimal (e.g. "/servers/socket/23").  */

  I saw that, but didn't know how to word the specification for the
naming of the socket server files.

> > /servers/socket/pflocal  A symbolic link to /servers/socket/1
> > /servers/socket/pfinet   A symbolic link to /servers/socket/2.
> 
> Shouldn't this be /servers/socket/local and /servers/socket/inet?

  Yes.

> > 6.2.x  /usr/share/info
> > 6.2.x  /usr/share/man  This directory is optional on a GNU system.
> > 6.2.x  /usr/X11R6 : X Window System, Version 11 Release 6
> 
> The /usr prefix should be removed...

  Unclear: if our interpretation is that the FHS specifies where the
files should be found, rather than 'how they get there' (which is the
reasoning by which we can say that, e.g., we've got a /usr/include
directory), then we should say that on a GNU system, it is not
mandatory to put a directory at /usr/share/man, right?  Alternatively,
saying in the context of the larger FHS that /share/man is not
required seems off, since there isn't any place in the FHS where
/share/man is required, no?

Thanks,
Richard




reply via email to

[Prev in Thread] Current Thread [Next in Thread]