Re: hurd does NOT need /hurd
On Mon, May 20, 2002 at 04:17:37PM +1000, Anthony Towns wrote:
> On Mon, May 20, 2002 at 07:52:11AM +0200, Marcus Brinkmann wrote:
> > > "/hurd" isn't needed simply as somewhere to put these translators,
> > > it's needed as a namespace to reference them.
> > That is a nice description for /servers actually (oh, no, another new top level
> > directory. But that was the last one, promised).
>
> 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. For example, if you
need to initiate a network socket connection, by default you contact the
server sitting at /servers/socket/2 (because 2 is the protocol number of PF_INET).
If login needs an authentication handle in exchange for a password, it
contacts the server at /servers/passwd.
By using the filesystem as the namespace for livint translators, we
eliminate the need for a seperate name server.
> (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.
> 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?
What about
$ (LD_LIBRARY_PATH=/lib/debug /bin/foobar)
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.
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.
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
--
To UNSUBSCRIBE, email to debian-hurd-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: