On Tue, May 30, 2017 at 5:36 PM, David Howells <dhowells@xxxxxxxxxx> wrote: > Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > >> Random notes: >> * "sb_config" looks rather odd in the current variant; mount_context, >> perhaps? Or fs_context, for that matter... Anyway, that's trivial. > > You can argue that one with Miklós. He argued against mount_context as I had > it originally. His point is that the same struct may be used when > reconfiguring an sb - which isn't exactly a mount operation (even though we do > it that day today with remount). I'm fine with fs_context, just leave "mount" out of this. Mounting is the act of attaching the root dentry to the mountpoint. fs_context is used for obtaining the root, but not for mounting itself, hence mount_context is misleading IMO. >> * what the hell is ms_flags thing doing in __vfs_new_sb_config()? >> It's a really vile mix of unrelated flags and operations we had in existing >> mount(2) ABI. With MS_KERNMOUNT thrown into that loo^Wmix. Sure, we need >> to parse the garbage fed to mount(2). And we need to pass that garbage to >> "legacy" types as well, but let's not inflict it upon the new mechanisms. > > I know, but we might get it from mount(2). I can tamp down the flag mask and > translate it from MS_*, but the MS_* flags are also stored in the superblock > (->s_flags). Good cleanup would be to just introduce a new set of flags for s_flags and leave MS_* usage solely for the legacy mount(2) interface. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
