Re: hurd does NOT need /hurd
On Sun, May 19, 2002 at 07:11:34PM -0500, Adam Heath wrote:
> Fine enough. But /lib/modules could also have a non-versioned subdirectory,
> /lib/modules/translators.
I don't see what fixes that. Translators are not libraries, not modules.
Why do you think that /lib/modules/translators is a good place for them?
> > 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.
Actually, they should. It should be /lib/linux or /lib/linux-modules, or
even just /lib/liblinux_modulename.so.
> > > 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.
Sorry, you lost me. I see no connection between this reply and the
paragraph you replied to.
> > 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.
If it would run multiple copies of a module, it would run multiple copies of
a module, not an external binary in user space.
> This is a limit of linux, not a limit of where in the FS they are placed.
If your whole point is that if Linux had something comparable to Hurd translators,
then where to put them, I would answer you that /lib/modules would not be the right
place for them. Assuming that they are comparable at the level that matters
for this decision.
> I say they are. You have not given any concrete answers. "/hurd is the
> place." is not a reason.
Try your rhetorics on someone else. I have given plenty of reasons. I have
given an introduction on the Hurd design and explained the semantical
difference between programs in /bin, /sbin, /libexec and /hurd. Now it is
on you to try to grasp this distinction, as fine as it is. The fact that
you are still comparing Hurd translators to Linux binary modules proves
clearly that the concept of the Hurd has not trickled in yet. I don't
blame you, it usually takes longer than one email and a quick intro to
understand those details, but don't blame me. Do some research on
hurd.gnu.org, maybe read my introductory talk on the Hurd and Thomas
design paper, and maybe try out a running Hurd system and play around
with translators a bit. Come back with concrete questions if you have them.
"I say they are." is not something that enables me to understand what
explanantion of mine you did not understand so far.
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: