On Thu, Apr 02, 2009 at 10:25:55AM -0400, Trond Myklebust wrote: > On Thu, 2009-04-02 at 10:22 -0400, J. Bruce Fields wrote: > > On Thu, Apr 02, 2009 at 10:16:40AM -0400, Trond Myklebust wrote: > > > On Thu, 2009-04-02 at 16:46 +0300, Benny Halevy wrote: > > > > On Apr. 02, 2009, 16:27 +0300, "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > > > > > On Thu, Apr 02, 2009 at 12:18:46PM +0300, Benny Halevy wrote: > > > > >> On Apr. 01, 2009, 18:32 +0300, Benny Halevy <bhalevy@xxxxxxxxxxx> wrote: > > > > >>> On Apr. 01, 2009, 17:07 +0300, Benny Halevy <bhalevy@xxxxxxxxxxx> wrote: > > > > >>>> On Apr. 01, 2009, 16:10 +0300, "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > > > > >>>>> On Wed, Apr 01, 2009 at 11:31:21AM +0300, Benny Halevy wrote: > > > > >>>>>> On Apr. 01, 2009, 7:33 +0300, "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > > > > >>>>>>> On Sat, Mar 28, 2009 at 11:31:09AM +0300, Benny Halevy wrote: > > > > >>>>>>>> Added CONFIG_NFSD_V4_1 and made it depend upon NFSD_V4 and EXPERIMENTAL > > > > >>>>>>>> Indicate that CONFIG_NFS_V4_1 is for NFS developers at the moment > > > > >>>>>>> Stupid question: do we need CONFIG_NFSD_V4_1 at all? How many people > > > > >>>>>>> will want to build a kernel with v4.0 but not v4.1? > > > > >> Bruce, with the patch below in place, would it be reasonable to > > > > >> remove CONFIG_NFSD_V4_1? > > > > > > > > > > It would be fine with me, but perhaps queuing that up as a separate > > > > > patch for 2.6.31 would be better than doing it at the last moment. > > > > > > > > It's not too hard to get rid of it now. > > > > I think it might be better than introducing a new config item > > > > to be removed in the next version. > > > > > > > > Trond, please speak up if you want to remove CONFIG_NFS_V4_1 as well. > > > > On the client side minorversion 1 will be used only if the user > > > > explicitly asked for it with mount -o minorversion=1. > > > > > > I'd feel more comfortable with being able to compile it out until the > > > stability of the code has been established. I'd certainly want to be > > > able to do that on the server side, since it has no other means to > > > restrict the protocol version should it turn out that NFSv4.1 has some > > > fatal condition. > > > > I think it's acceptable given an interface that allows choosing the > > supported minorversion at runtime (and that defaults 4.1 to off). > > Is there such an interface on the server? That's the patch Benny just posted. It seems like a pretty simple extension of the existing version-choosing interface (/proc/fs/nfsd/versions), though I think the version he posted defaults 4.1 to on? I need to take another look. --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
