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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
