> On Wed, Feb 20, 2008 at 04:39:15PM +0100, Miklos Szeredi wrote: > > > mountinfo - IMO needs a sane discussion of what and how should be shown > > > wrt propagation state > > > > Here's my take on the matter. > > > > The propagation tree can be either be represented > > > > 1) "from root to leaf" listing members of peer groups and their > > slaves explicitly, > > > > 2) or "from leaf to root" by identifying each peer group and then for > > each mount showing the id of its own group and the id of the group's > > master. > > > > 2) can have two variants: > > > > 2a) id of peer group is constant in time > > > > 2b) id of peer group may change > > > > The current patch does 2b). Having a fixed id for each peer group > > would mean introducing a new object to anchor the peer group into, > > which would add complexity to the whole thing. > > > > All of these are implementable, just need to decide which one we want. > > Eh... Much more interesting question: since the propagation tree spans > multiple namespaces in a lot of normal uses, how do we deal with > reconstructing propagation through the parts that are not present in > our namespace? Moreover, what should and what should not be kept private > to namespace? Full exposure of mount trees is definitely over the top > (it shows potentially sensitive information), so we probably want less > than that. > > FWIW, my gut feeling is that for each peer group that intersects with our > namespace we ought to expose in some form > * all vfsmounts belonging to that intesection > * the nearest dominating peer group (== master (of master ...) of) > that also has a non-empty intersection with our namespace > > It's less about the form of representation (after all, we generate poll > events when contents of that sucker changes, so one *can* get a consistent > snapshot of the entire thing) and more about having it self-contained > when we have namespaces in the play. > > IOW, the data in there should give answers to questions that make sense. > "Do events get propagated from this vfsmount I have to that vfsmount I have?" > is a meaningful one; ditto for "are events here propagated to somewhere I > don't see?" or "are events getting propagated here from somewhere I don't > see?".
Well, assuming you see only one namespace. When I'm experimenting with namespaces and propagations, I see both (each in a separate xterm) and I do want to know how propagation between them happens. Your suggestion doesn't deal with that problem. Otherwise, yes it makes sense to have a consistent view of the tree shown for each namespace. Perhaps the solution is to restrict viewing the whole tree to privileged processes. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
