On Thu, Nov 13, 2014 at 03:22:20PM -0500, Trond Myklebust wrote: > On Thu, Nov 13, 2014 at 2:55 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > On Thu, Nov 13, 2014 at 02:26:20PM -0500, Trond Myklebust wrote: > >> Secondly, that's a layering violation. The main nfs module has no > >> business knowing anything about the sub-modules other than how to load > >> them when needed. If I want to recompile my NFSv4 module to add > >> NFSv4.2 support, then I shouldn't have to recompile the entire > >> contents of my nfs directory. > > > > You don't have to, you just have to mount with -oversion=4.2 in that > > case. > > > > The compile-time constant here is just a default starting point for > > negotation. > > > > As long as there's no stable kernel API, and end users don't routinely > > load modules from the future, the nfs module seems like a reasonable > > enough place to store the default minorversion. > > > > It is reasonable if and only if your process can load modules and read > procfs, neither of which are guaranteed in all situations where we may > want to use mount.nfs. Yeah, OK, so if we have to assume access to not much more than the mount syscall then I give up. (I guess the only way to let the nfs module decide the default in that case would be to let the kernel do more of the negotation?) --b. -- 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
