Re: hurd does NOT need /hurd
On Wed, May 22, 2002 at 01:53:34PM -0600, Jason Gunthorpe wrote:
> Well, if the hurd has retained the traditional microkernel design, what
> they call a translator really is just an ordinary process, like any other.
>
> The only distinction is that it has an IPC connection (this is what a port
> essentially is in mach) to whatever is managing the filesystem namespace,
> so requests for it's section get routed to it.
Yes, exactly.
> It sounds like with HURD the only way to get the IPC connection is to
> have another process (perhaps with more privilage?) create it.
>
> In every other MK system I've used these sorts of IPC connections could be
> created by a process on it's own. So for instance on QNX you could just go
> 'Fsys.ext2 /dev/... /mnt/foo &' and it would make it's own arrangements
> with the namespace manager to own /mnt/foo.
It could do it, but the problem is that referring by name is a horrible
thing to do. Path names can change. If you move a directory, you don't
want to change all your translator settings. Also, the filename depends
heavily on the context. It introduces a race condition, and it isn't even
always possible to have a filename. For example, you can create "temporary
files" in the Hurd without creating a file entry in the directory for a
short time (eg, the unlink happens atomically in the server). This is indeed
how tmpfile() is implemented. If you want to attach a translator to that
file, there would be no way to do it if you only have the above syntax.
Another example is the --chroot option to settrans which starts the
translator without attaching it to the parent filesystem, and executes a
command chrooted in that new filesystem.
Well, I assume that QNX and such systems can do the same trick some way,
maybe with a library. But in the Hurd, this is the only way, because it
allows to implement a new feature in settrans and then use that with all
servers (like the --chroot feature).
Filenames don't fly far at all here. I am not sure if or why they are
sufficient for other systems that are organized similarly.
> Anyhow, just to chime in - other MK Os's like QNX and NTO keep their
> 'special' processes (filesystems, TCP/IP, drivers, etc) in /[s]bin or
> /usr/[s]bin. Most of the time mount or other front ends will exec them
> for the user, but you can run them on their own if you really want to.
If they are invoked the way you wrote it above, putting them into the PATH
makes perfectly sense.
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-hurd-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: