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

Re: hurd does NOT need /hurd

On Mon, 20 May 2002, Marcus Brinkmann wrote:

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

Fine enough.  But /lib/modules could also have a non-versioned subdirectory,

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

I said the ideas, not the binaries themselves.

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

So why make it hurd specific?  I mean, even linux's kernel modules don't have
linux in the directory name.

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

Use binfmt_misc, and Linux can run anything.

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

Just because linux doesn't run several copies of a module, on behalf of users,
don't meant it can't.  It's just no one has introduced the capabilities yet.

This is a limit of linux, not a limit of where in the FS they are placed.

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

I say they are.  You have not given any concrete answers.  "/hurd is the
place." is not a reason.

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

Reply to: