Re: hurd does NOT need /hurd
On Mon, May 20, 2002 at 03:16:04PM +1000, Anthony Towns wrote:
> Using an analogy to Linux, it's not so much that it contains programs (in
> the /usr/bin sense), it's more that it contains "filesystem definitions".
> That those happen to be programs is interesting, but not particularly
> important. So, where you'd type:
>
> mount -t msdos /dev/hda3 /mnt # in Linux
>
> you type
>
> settrans -a /mnt /hurd/msdos /dev/hda3 # in Hurd
>
> (assume there's a "/dev" translator setup if you have to)
This is how you will look at it when you only know mount, and this is
actually almost exactly what the Hurd mount command does for you. And
at some later time you will explore it more fully and notice that you
can stick a lot of more interesting commands into settrans after the
/mnt (I gave two examples, one using /bin/sh and another using
/bin/rpctrace in another mail here).
What is happening if you type that command you are running the /hurd/msdos
program in a specific environment set up by settrans. With environment I
don't mean ENV, but a special bootstrap port. The bootstrap port allows the
filesystem to connect to its parent filesystem. Conveniently the bootstrap
port is inherited by fork and exec, so you can just pass it through programs
like /bin/sh -c.
> "/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).
> > > In the current FHS, there is documentation about /lib/modules.
> > Linux modules are not even remotely comparable to Hurd servers. Linux
> > modules are comparable to other binary plugins that are dynamically loaded
> > and unloaded at run time by some programs that support plugins.
>
> Sure they are. Hurd servers may have signficant advantages over Linux
> modules, but they have the same broad aim. The latter was even partially
> inspired by the former, aiui.
There are some specific problems that both solve, but they are different
enough that it is dangerous to mix them up by presenting them side by side
without explaining the differences thoroughly. I have heard quite often
terms like "kernel extensions" in this thread when people talked about
Hurd servers, this is not something one should encourage.
> > /lib/modules is completely wrong. Hurd servers are neither a library nor
> > modules, nor non-executable architecture specific data or anything of that
> > sort.
>
> "lib" isn't just for "libraries", it's "object files, libraries, and
> internal binaries that are not intended to be executed directly by users
> or shell scripts"
ah well, that must be the /libexec devil in me ;)
> (well, /usr/lib, anyway). The latter seems a pretty
> accurate description,
The Hurd translators are not internal binaries, though. They are not directly
executed by users, but especially in the settrans -a case above they are
explicitely invoked by the user, with the help of settrans.
> Anyway, this is all pretty irrelevant. If policy's not meant to be a
> stick, then people shouldn't be trying to change however many years of
> existing practice in the Hurd just for fun.
Amen.
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-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: