On Wed, 22 May 2002, Marcus Brinkmann wrote:
> On Wed, May 22, 2002 at 04:43:44PM +0200, Emile van Bergen wrote:
> > 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?
>
> They are ELF executables.
Well, duh. But you probably mean that in the stricter sense, i.e. a
plain ELF executable that only specifies its single ELF starting point.
> > 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?
>
> It does some special Hurd specific set up and then does exec. Our exec
> is written in a way to keep the Hurd specific setup.
The only thing I could find is that it passes down an open Mach port to
the higher-level filesystem server for the inode.
Unix has something very similar: the ability to pass down an open file
descriptor. But nobody's arguing that Debian should have all its
programs that are essentially only useful as filters, removed from /bin.
> I thank you for your opinion on this, but we really have to move on.
You keep trying to blow a smoke screen around the architectural issue.
I don't understand why. Remember that *you* want something from Debian,
(the addition of /hurd), not the other way around. *You* are the one
under the obligation to answer *why* you *need* a separate /hurd
directory.
> This issue was pondered to death, and if you are really interested
> in it at this level of detail, you can install Debian GNU/Hurd, and get
> into it, and post design ideas to help-hurd@gnu.org.
I am very interested in userspace drivers and userspace filesystems. But
I'm still trying to determine whether it's worth my while to actually
invest time in the Hurd.
> > (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).
>
> There are programs that can only useful to root, even on the Hurd.
> There are much less of them, but some there are. Those are in /sbin.
I can understand if you haven't had much time to read my message, but
please, that's a useless answer.
It only tells me (again) that you consider a somewhat vague concept of
usefulness to particular user categories, important for defining
directory structure, as opposed to much harder criteria based on the
allowed protocol(s) for running those executables.
Ok, I'll admit that it's off-topic, but I'd say that if you really want
to adhere to some "intended use"-centric directory-of-binaries approach,
then you should get rid of the whole {/,/usr}/[s]bin concept as a
gathering place for all the system's programs, but install each package
under its own directory, like /pkg/<packagename>/. Then, make
/etc/<packagename> a symlink to /pkg/packagename/etc, and create a
/bin/<category> directory for each user category (sysadmin, netadmin,
storageadmin, mailadmin, graphics-artist, c-developer, general-shell,
scheduled-command, hurd-filesystem), which contains symlinks to the
binaries in the various /pkg/<packagename>/bin directories for each of
the packages that you recognise to be useful for those different
user/use categories.
You can then even use those user category-centric directories as the
PATH for the users in those categories.
It's not exactly FHS-conformant, true. But it does make the concept
you're advocating actually useful, perhaps.
But while we're sticking to the FHS' *spirit* of {/,/usr}/bin as a
gathering place of *all* executables that can be useful to users,
regardless of primary intended use, regardless of execution environment,
whether that's as a shell command, in scripts, as a filter (also has its
execution environment set up in a 'special' way: open filedescriptor is
passed down), or whatever, I cannot see why translators, which are
programs that are valid as shell commands but primarily intended to be
ran by the filesystem on behalf of the user who attaches it to an inode,
must live outside of /bin.
You could just as well argue that program that are primarily intended to
be ran from cron should be put somewhere other than /bin, even though a
user explicitly specifies himself that the program must be run on his
own behalf, and even though the program follows normal exec()-style
executable semantics. And naturally, that's nonsense.
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