On Fri, Feb 18, 2011 at 10:45:12AM +0800, Steven Liu wrote: > Hi AI Viro, > > I have saw this message, :) > > I think the nfs is using fs_type->get_sb, but it isn't using > get_sb_bdev(or get_sb_nodev) . > So if the nfs cannot let > struct dentry *(*mount) (struct file_system_type *, int, > const char *, void *); > to replace > > int (*get_sb) (struct file_system_type *, int, > const char *, void *, struct vfsmount *); > Now, this patch cannot influence nfs normal use. > Because get_sb is not must use get_sb_bdev or get_sb_nodev to get mnt, > All the filesystem are using mount_bdev mount_nodev now, but it > isn't called > by get_sb,is called by *mount. Do you agreed with me? Sigh... Yes, and it is irrelevant. There's simply no reason to remove that stuff before the next merge window, when ->get_sb() is going to go away _anyway_, along with those helpers. I am not saying that it can't be done right now; there's simply no point in doing so. I don't particulary care about hurting out-of-tree filesystems and if we had ->mnt_devname series in this window I'd cheerfully ripped ->get_sb() out and let them deal with it. However, I don't see any reasons for removing the helpers in this cycle. What for? To force the (trivial) switch to ->mount() in out-of-tree block filesystems one cycle earlier? -- 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
