On Thu, 13 Oct 2005, Mike Waychison wrote:
> Ram wrote:
> > On Tue, Oct 04, 2005 at 12:14:47PM -0700, David Leimbach wrote:
> >
> >>Hmm no responses on this thread a couple days now. I guess:
> >>
> >>1) No one cares about private namespaces or the fact that they make
> >>/etc/mtab totally inconsistent.
> >>2) Private Namespaces aren't important to anyone and will never be
> >>robust unless someone who cares, like me, takes it over somehow.
> >>3) Everyone is busy with their own shit and doesn't want to deal with
> >>me or mine right now.
> >>
> >>I'm seriously hoping it's 3 :). 2 Is acceptable too of course. I
> >>think this is important and I want to know more about the innards
> >>anyway. 1 would make me sad as I think Linux can really show other
> >>Unix's what-for here when it comes to showing off how good the VFS can
> >>be.
> >
> >
> > This becomes even more intresting when sharedsubtree gets added to
> > the equation. One would like to know all the mounts in its namesapace
> > and than all the mounts it propagates to which could include mounts in
> > other namespaces too..
> >
> > I guess some interface that meets the following needs would eventually
> > be needed:
> >
> > 1. what are all the mounts in my namespace ?
> > A. what are the attributes of each of the mounts?
> > a. where is it mounted
> > b. who is its parent
> > c. what is it mounted from
> > d. what are the attributes of its mount
> > e. what are its peer mounts (I suspect some kind
> > of identifier has
> > to be associated with each mount)
> > f. if it has a master mount where is it
> > g. what are its slave mounts.at
> > (note: e, f, g can point to mounts in other namespaces)
> > 2. what are the attributes of my namespace?
> > a. what is the parent namespace? ( I suspect some kind
> > of identifier has to associated
> > with each namespace, pid of the cloned
> > process?)
> > b. what are my children namespace?
> >
> > 3. which processes can access my namespace?
> >
> >
> > And I don't think /etc/mtab can do a decent job with this, because it
> > would not know where all the mounts propagate, when it attempts a mount.
> > Only the kernel would know, and hence all the commands who depend on
> > /etc/mtab may have to depend on some /proc or maybe /sysfs interface to
> > do a descent job.
> >
>
> Or, you bite the bullet and fix /proc/mounts and let distributions bind
> mount /proc/mounts over /etc/mtab.
>
> Sun recognized this as a problem a long time ago and /etc/mnttab has
> been magic for quite some time now.
Don't forget to update mount as well.
Ian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
