On Fri, Jan 14, 2011 at 11:43:48AM +0000, David Howells wrote:
> I presume that people aren't expected to do things like do_move_mount() here,
> but might they want to do a bind mount? Or do we just say if they want to do
> something more exotic than do_add_mount(), they have to follow path (b)?
bind can be done just fine - all you need is to clone the vfsmount (or subtree)
you want to bind there and return the sucker.
> It would be simpler, perhaps, to allow d_automount() to return the list also:
>
> struct vfsmount *(*d_automount)(struct path *mountpoint,
> struct list_head **expiry_list_to_use);
>
> This pointer can then be passed directly to do_add_mount() and we don't have
> to worry about having an extra reference or cleaning up the list on error.
Let's not. For one thing, getting rid of that argument in do_add_mount() is
a Good Thing(tm). For another, I don't see any problem with having
mnt_set_expiry(mnt, list)
and
mnt_clear_expiry(mnt)
in fs/namespace.c. Moreover, as you've mentioned in another followup, we
want the list to be non-empty until we either put the vfsmount in place
or decide to discard it, since we don't want fs to decide that the list is
empty and no expiry runs need to be scheduled anymore.
One more thing: do_add_mount() would happily get unexported and go to
fs/internal.h, which is also a good thing; it's too easy to abuse.
_______________________________________________
autofs mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/autofs
