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

Re: hurd does NOT need /hurd

On Sun, May 19, 2002 at 06:28:59PM -0500, Adam Heath wrote:
> First, some problems about /hurd that have come up on irc just now.
> 1) is /hurd versioned?  Or is /hurd a 'special' filesystem(kinda like devfs
>    for linux), that lists the available services that have been compiled into
>    the kernel?

Have you read my mail in response to Joey Hess?  I don't know what you
discussed on IRC, but /hurd is a directory.  It contains programs.  You
could also ask if /bin is versioned.

The Hurd servers in /hurd indeed usualy conform to the Hurd server interface
as defined by /include/hurd/*.defs.  This interface is _stable_.  There is
no need to version the binary interface as it is not allowed to change.

This is all user space.  The kernel has nothing to do with it at all.
> 2) Could the ideas that the items placed in /hurd be useful outside of hurd?
>    Ie, could other operating systems make use of translators?

I don't know of any free Unix-like operating system that could feasibly make
use of them the way the Hurd does.  This answer is probably as vague as the
question, so feel free to concretize.

> Now, for some other analogies, to existing practices, showing that /hurd is
> not needed, *at all*.

Well, you can also lump it all into some other directory, ignoring the
semantics completely.  A directory is only a place to store files in after

> 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.

Linux modules are not used by users.  They are often not even loaded or
unloaded manually (insmod), but via other tools like modprobe and
modutils.conf (or whatever the module loading mechanism of the day is in the
Linux world) or even automatically by the kernel on demand.

> I also wonder if the idea of filesystem translation could be useful outside of
> hurd.

Sure it is a useful concept.  That's why Thomas designed the Hurd around it.

> It's just that linux doesn't have a well-defined way of having translators run
> as normal users(most run as root, or something).

Linux has no way to run arbitrary translators by untrusted users.  It
completely lacks the security concepts required to make it feasible.

> So, why then do we really need /hurd?  What are the *real* reasons?

There is a need for a directory that contains executables that should not be
in the PATH but can be run as Hurd servers if given a bootstrap port.  This
is /hurd.  /servers is already taken, which provides rendevouz ports for
servers to look up a communication port to other servers.

/lib/modules is completely wrong.  Hurd servers are neither a library nor
modules, nor non-executable architecture specific data or anything of that


`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org

To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: