Re: hurd does NOT need /hurd
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.
> > (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 ;)
> > 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.
> 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.
> 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...
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. 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.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``BAM! Science triumphs again!''
-- http://www.angryflower.com/vegeta.gif
--
To UNSUBSCRIBE, email to debian-hurd-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: