Yes, that is, I think, the correct thing to do... but see also below.
> > I don't see that your argument is a problem... anyone who wants something
> > different in their namespace is going to have to change things anyway.
> And how would they do it? You get mount triggered by stepping on dentry.
I think that's the correct behaviour for an automounter, except for stat(),
which I'd prefer _not_ to cause this (so you can "browse").
> Your kern_automount() will then create a new vfsmount and slap it on the
> tree. Again, regardless of the namespace we are in / vfsmount we are
> looking at / etc.
Looking at my code, I should probably use the semaphore from the namespace
pointed to by the vfsmount I'm going to be mounting on, just in case we've
managed to cross into someone else's namespace:
int kern_automount(struct vfsmount *on_mnt, struct dentry *on_dentry)
+ struct namespace *namespace = on_mnt->mnt_namespace;
struct nameidata nd;
> I have two namespaces. One of them has filesystem A mounted on /usr/include.
> Another - on /usr/local/include. The first one wants /usr/include/foo1 trigger
> mounting B and /usr/include/foo2 trigger mounting C. The second one wants
> /usr/local/include/foo1 trigger mounting D and /usr/local/include/foo2 not
> trigger anything.
> Namespaces are completely unrelated - I have them set for two different
> users that happen to need some common files, but otherwise have very
> different environments.
Not exactly unrelated. If namespace A derives from namespace B during clone(),
then I would consider B should behave exactly as A until modified - including
> Could you describe what that "having to change things" would involve?
Well, if you, say, cloned a shell with its own namespace with the intent of
rearranging its namespace for that user, then I think it would be fair to say
that you'd have to "change things" at some point (ie: use (u)mount to
rearrange the topology).
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/