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 | [EMAIL PROTECTED] tel. +31 (0)70 3906153 | http://www.e-advies.info -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
