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,
/lib/modules/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.
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: