> 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/