Messages in this thread | | | Date | Tue, 15 Jun 1999 09:38:48 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: initrd redesign (was Re: Partition nightmare Was: Migrating to larger numbers) |
| |
On Tue, 15 Jun 1999, Werner Almesberger wrote:
> Alexander Viro wrote: > > Plan 9 ones. > > Ah, this. Is this something that somebody is working on ? People have been
Yes.
> talking about Plan 9 name spaces for many years, but it seems that not too > much emerged from that.
Look at it that way: we have a bunch of trees internally (dentry trees). And we have a couple of mappings (d_covers and d_mounts) that join them into the namespace. OK. Now, let's define namespace as such pair of mappings (mutually inverse, indeed). IOW, a binary relation between the dentries. Notice that almost all work is done within the trees - just a couple of functions deals with crossing their boundaries. Current implementation uses a couple of pointers in struct dentry. Now, let's introduce a cache of triples <namespace ID, dentry-from, dentry-to> and replace traversing the mountpoint with cache lookup. With a reasonable hash-function it's not that slower than the current variant (the difference will be lost in noise from lookup_dentry() internals). > >> Isn't the device file sufficient ? > > > > For NFS? > > Major 0, minor dynamically assigned. Fairly trivial to use with something > like the /proc/mount-devs I've proposed. As far as the device file is > concerned, you can either > > - create it on the fly (e.g. LILO does that if it doesn't find anything > suitable in /dev) > - populate /dev with unnamed0, unnamed1, etc. > - get devfs to do all this for you (if you have devfs) No, thanks. > - create a /proc/unnamed-dev/<number> virtual directory In *each* instance of proc, you mean.
There is one big problem: what will you do with such devices? What kind of semantics can you have for them? Introducing them just to close the kludge with NFS mounting... ;-/ IMHO it's fixing a kludge with worse one...
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |