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

Re: hurd does NOT need /hurd



On Mon, May 20, 2002 at 05:04:37PM +1000, Anthony Towns wrote:
> On Mon, May 20, 2002 at 08:39:12AM +0200, Marcus Brinkmann wrote:
> > > Hrm? Why are you typing "/hurd/foo" in your settrans command instead of
> > > "/servers/foo" then? What's /servers for?
> > /servers is an area where active translators reside.  
> 
> Ah! That would be a very /proc-ish namespace then.

No. It's not to give information. You can get the information stored
in the Linux proce using RPCs to servers. /servers is a way to find
those servers. We could write a /proc translators too which use those
RPCs to get the information, doing this could be a nice way for a new
developer to get familair with the Hurd.
 
> > > (If /hurd *is* just somewhere to store them and isn't meant to be a
> > > convenient namespace,
> > Oh, it is a convenient namespace for the server binaries.  It's just the way
> > you formulate it, "namespace" and "referencing them" that made me think of
> > the name service and active translators and their rendevouz ports.
> 
> Which makes /hurd be the namespace for inactive servers, and /servers be
> the namespace for activer servers. Hrm. If I understand this right, it
> probably would've been tidier to have:
> 
> 	/hurd/msdos
> 	/hurd/active/socket/2
> 
> under a single hierarchy. "active" should probably be spelt "actv" for Unix
> compatability ;)

No. /hurd is the place in the filesystem where the binaries of the
system servers live. I don't see why we need to change this location.

It doesn't matter whether the servers in /servers are passive or
active. It's just that when the system needs to talk to some server it
should talk to a node in /servers.
 
> > > They're referred to by the user, but they're not invoked by the user.
> > Uh, they are.  I mean.  If the user runs
> > $ /bin/sh -c "LD_LIBRARY_PATH=/lib/debug /bin/foobar"
> > does he invoke /bin/foobar?
> 
> No, he invokes the shell and tells it to run /bin/foobar. If he were just
> invoking foobar, he'd have written
> 
> 	$ LD_LIBRARY_PATH=/lib/debug foobar
> 
> and that's why it's in the PATH.

It's just that the shell doesn't know about translators but does know
about normal programs. If you would change that, it would be the
same.
 
> > does the user here invoke /bin/foobar?  I think it is pretty obvious that
> > the purpose here is not to run the shell, and /bin/foobar is some indirectly
> > referred to data file that happens to be an executable.  The purpose here is
> > directly to get /bin/foobar running in a certain environment.
> 
> Well, for the "settrans" stuff, the purpose is to make some files
> available in the filesystem. That a new process happens to start up to
> do it, and that you have to give the name of the executable, is really
> fairly irrelevant to your purpose.
> 
> What you're actually typing is pretty relevant: settrans (the program
> that organises all this) needs to be in the PATH, and the name of your
> server (/hurd/msdos) needs to be fairly easy to type.
> 
> There may be other interesting analogies that can be drawn for OS
> theorists, or kernel hackers, or whatever, but the only goals that are
> particularly relevant to the file layout are the above two, afaics.

You can actually think about settrans as an ld.so for
translators. It's just a loader which sets up the environment for the
translator.
 
> > And this is the case with programs in /hurd.  It's just that the special
> > environment is nothing that can be provided by just Unix, so having those
> > programs in the PATH is pointless.  That's why they aren't in /bin after all.
> > From my personal experience, they are much closer to /bin than /lib.
> 
> That's only because you're a libexec freak...

No, because he wants to have a clean filesystem and not a big mess.

> Really, it's quite simple: you don't run them from a prompt directly,
> so they don't go in $PATH, and they're programs. Therefore they go in
> /usr/lib somewhere, or you invent somewhere new for them to go. 

/lib is for libraries, not programs. We already invented some new
place, that's /hurd. I haven't seen a reason why that place is wrong.

> But
> you're not forced into the latter just because they don't fit in /bin:
> on that score, /usr/lib is a perfectly fine place for them.

No, /lib is for libraries. We should not put everything in /lib when
no other directory exists. Maybe we should create a new directory then.

Jeroen Dekkers
-- 
Jabber ID: jdekkers@jabber.org  IRC ID: jeroen@openprojects
GNU supporter - http://www.gnu.org

Attachment: pgpuWHoOIw0Ja.pgp
Description: PGP signature


Reply to: