Re: [RFC][PATCH 1/8] namespace: use global namespace semaphore

[raven@themaw.net]

On Fri, 3 Jun 2005, Miklos Szeredi wrote:

> > > > > Can someone explain, why autofs needs to walk the mount tree?
> > > > 
> > > > I generally don't need to walk the vfsmount tree except during
> > > > expire (ref may_umount_tree in namespace.c). What I find is that
> > > > I often need to locate a sibling vfsmount given a parent and a
> > > > dentry (aka. lookup_mnt).  This is because, after a mount is
> > > > triggered (the daemon is notified and does the mount) I need it
> > > > in order to follow it. I expect Mike has similar needs.
> > > 
> > > You can use follow_down(), which does just this, and is already
> > > exported.
> > 
> > Sure, but that was the subject of this thread in the begining.
> 
> I think you're mixing it with follow_link().  follow_down() is just a
> nice wrapper for lookup_mnt(), and is exported to modules.
> 
> > The nameidata vfsmount entry is not upto date when this method is called.
> > Therefore I need to look it up.
> > 
> > I could propose a change to link_path_walk to update it prior to the 
> > call but then I can't have a tarball that can be used to build the module 
> > without rebuilding the kernel.
> > 
> > I was planning on doing this to facilitate testing.
> > 
> > Do you really think that it's OK to remove long standing structure 
> > fields on the strength that no other kernel code is using them?
> 
> Yes, if it's not part of an interface.

What interface?

I'm not aware of any clearly defined API for access to in kernel functions 
for the VFS except for the various operations methods. Unfortuneatly, any 
struct that is passed to them should be largely imutable as well. Which 
ultimeatly covers the structs we are talking about here.

All I see is people taking the oppertunity to stop exporting functions 
without consideration to what should be considered part of an API.

Some companies do this really well to foster development.

> 
> > What about the externally developed modules from other places?
> 
> I think it's usually understood, that you shouldn't rely on
> implementation details, or otherwise have to face the consequences.

I dont think that really good enough for a viable software platform.

> 
> But in this case there's no such problem I think, because you can
> solve this with existing exported interfaces, and don't have to bother
> about mnt_list.

Yes. That would be the case except there's a reference held to the 
vfsmount in the struct path prior to point at which follow_link is called, 
which I don't think can be obtained.

In any case I'll find a way to work around it.

Ian