Re: hurd does NOT need /hurd
Hi,
On Wed, 22 May 2002, Marcus Brinkmann wrote:
> On Wed, May 22, 2002 at 02:31:56PM +0200, Emile van Bergen wrote:
>
> > On Mon, 20 May 2002, Marcus Brinkmann wrote:
> >
> > > 'You don't want them to be visible in /bin because running them on the
> > > command line the normal way fails with "Must be started as translator."'
> >
> > I think that's a very feeble reason. Either you say that the image is
> > intended to be ran by users (in a particular way), or you say users
> > aren't responsible enough to decide when and how they want to run it --
> > but you can't have it both ways at once.
>
> You are thinking Unix. GNU is not Unix.
Quite fundamentally so, if you have two very different protocols for
dealing with program images: Unix-style exec() and
exec()-in-a-settrans-environment.
But essentially I think that this difference is not needed to accomplish
the Hurd's great central concept, namely that a *user* can run *normal
programs* to populate the filesystem namespace. (Or vice versa, that
users can use the filesystem namespace to interact with *normal
programs*). At least that's what I understand translators are all about?
I'm essentially asking the question: are those 'normal' programs indeed
normal programs, in the sense of some image that is loaded or mapped
into a separate address space, specifying a single point of entry (being
allowed to register other rendezvous points only subsequently), or are
translators something else in that respect?
I.e. does the filesystem code run a translator via some form of exec()
when the translator gets started on demand, or does settrans already set
up the process space, load/map the translator's code, and register
special entry points with the filesystem?
If it's the latter, and it's not exec(), then the settrans concept can
be exceptionally well modelled as an ELF loader; the difference being
that it does not jump to the entry point after setting up the process
space, but registering entry points with the filesystem.
But if it's exec(), and it seems like it is, then essentially, normal
unix semantics apply when it comes to programs. And in that case, the
whole /bin-vs.-/hurd discussion starts being a /bin-vs-/sbin discussion,
where the only difference is essentially PATH, as something influencing
the behaviour of the shell.
And I personally think separating /bin from /sbin is nonsense too, even
in a classic Unix environment: it's useless for security, because you
must already assume that a user can run any image on behalf of himself
anyway if you want to build any real security, and it's also useless for
guiding the user by showing what the available commands are, because
they are too many and they are too abbreviated for 'ls /bin' to be of
any help these days. But that aside.
However, the fact that (the filesystem manager of) the Hurd can *exec()*
these programs on demand, doesn't change a thing. The Linux kernel can
also exec programs on demand; I can register a module loader by typing
'echo /my/special/modprobe > /proc/sys/kernel/modprobe', or register a
binary image loader by echoing to /proc/sys/fs/binfmt_misc/register. But
Linux doesn't need a special path to store those programs either. I can
store them in ~/bin if I want. That's what the hurd is all about, right?
Let's be fair, if you're prepared to 'think out of the box' when it
comes to exec(), then you can at least 'think out of the box' when it
comes to the shell, and not assume the way it maps commands to programs,
using PATH, as a given, and use that as an argument for /hurd as a
separate directory.
> PATH is the thing your shell looks in if it sees an unqualified program
> name on the start of the command line to run.
>
> It is not useful for a translator to be in the PATH because it does not
> do a lot of useful things when run this way. Because this is not how
> translators are intended to be invoked.
>
> > Look at this. A lot of programs that reside in /bin make no sense to
> > users who do not know how to run them, i.e. who do not know what
> > arguments (or prefix, in your case settrans) to supply. But they still
> > are in /bin
>
> There is quite a difference between choosing the right arguments and
> invoking a program through settrans. Give another example where a
> large set of programs in /bin can only be run meaningfully by putting
> them into a special (non-Unixish) environment.
That's a good point. But if you already explicitly put the program in a
separate environment (using a loader that sets it up), why the need for
an explicit, separate directory? Make up your mind, I'd say.
> > So, *nix only has programs you can run, and IMHO the distinction is kind
> > of moot. I think /bin is an excellent place, and possibly you could
> > change the ELF loader for those programs from /lib/ld.so to
> > /bin/ld.settrans, and make the new settrans take and remove its own
> > arguments from the argv supplied to the translator. This may be a wild
> > idea though, but hey.
>
> You mean doing another mistake to back up the first one? Really, this
> is not how we work.
My point is that I see you forcing the use of /hurd to back up the
mistake of PATH, because you assume a Unix shell.
> I have sympathy for trying to unify everything, but it can be taken too
> far. In particular, to unify things that are fundamentally different
> is wrong.
True. But I'm interested what the fundamental difference is, see the
questions above.
If the programs in /bin are not invoked using a different protocol from
those in /hurd (that is, both use a separate process space and single
entry point, either by the shell doing exec() or on demand by the Hurd
filesystem), then I don't see enough difference (other than the
PATH-based mapping from programs to user commands), to warrant a
different directory.
(And as said, neither does /sbin IMHO, and I'm sure, coming from the
Hurd philosophy that empowers the user and makes him fully responsible
for his own part of the (file)system, you'll agree).
Cheers,
Emile.
--
E-Advies / Emile van Bergen | e-advies@evbergen.xs4all.nl
tel. +31 (0)70 3906153 | http://www.e-advies.info
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: