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. Cheers Trond -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- 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
