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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
