Re: [9fans] bind, ns weirdness

["Russ Cox" <rsc@plan9.bell-labs.com>]

ns is not manipulating the data.
it is showing you the internal
kernel data structures.  the kernel
doesn't keep the history of every
mount, bind, unmount, and in fact
the kernel doesn't keep the structure
as a list.  it keeps it as a hash table
for quick access, and the mount points
are represented by chans (think vnodes)
rather than actual path strings.  
when you look at just the strings
(as happens when it is presented in
the ns file) there is no guarantee that
the names are still valid.

as you point out the fundamental
problem here is that unmount removes
things from the hash table (and thus from
the list presented in /proc/$pid/ns),
things that other binds or mounts might
have depended on to make sense of the
names at the time.

it is entirely reasonable that unmount
removes things from the hash table:
they're gone!  then the chans can be
closed, and the resources reused.
in order to keep the entries in /proc/$pid/ns
around, the chans would have to be
kept open, which is against the point 
of unmount.  unmount means release
this binding, not make it invisible but
hold onto the resources.

perhaps some stub should remain in
the in-order list that has an empty 
chan structure with just a name,
so that the ns list is correct.  perhaps.