On Wed, Feb 20, 2008 at 04:39:15PM +0100, Miklos Szeredi wrote:
quoted text
> > 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?".

Dumping pieces of raw graph, with IDs of nodes we can't see and without
any way to connect those pieces, OTOH, doesn't make much sense.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html