Re: hurd does NOT need /hurd
On Thu, 23 May 2002, Marcus Brinkmann wrote:
> > 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
Well, the model most folks have followed is one similar to how mount
operates in traditional unix. The namespace manager could only delegate
a tree (or single file) to a single other process - so in practice the
only concern ultimately was moving directories around. Races never existed
because all operations created something new - ie if you mounted /mnt/foo
then the inode /mnt/foo does not have to exist - it is created by
attaching to it.
I guess HURD passive translators are implemented with a special inode if
they persist in the filesystem and follow renames around properly, so it
certainly makes alot of sense to invoke them them without a pathname
reference.
QNX4 is somewhat limited in this regard, it's IPC is entirely
connectionless, so being able to pass an already prepared context to a
child via exec is not easy to do. The general solution often was to just
have environment variables or command line parameters to handle various
cases - (or try not to do it at all :>). Having connection based IPC like
MACH (or NTO, which just used POSIX fd's) makes a whole lot of problems
much easier.
Jason
--
To UNSUBSCRIBE, email to debian-hurd-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: