On Jul 8, 2013, at 8:53 AM, Steve Dickson <SteveD@xxxxxxxxxx> wrote: > > > On 05/07/13 10:59, Chuck Lever wrote: >> Hi Steve- >> >> On Jul 5, 2013, at 7:31 AM, Steve Dickson <SteveD@xxxxxxxxxx> wrote: >> >>> Hey, >>> >>> On 03/07/13 09:19, Chuck Lever wrote: >>>> Hi- >>>> >>>> I'm not opposed to this change, but we should have some public discussion about it first. >>>> >>>> If we make this proposed upstream change, NFSv2 will be built far less often and will be >>>> a magnet for code rot. It might make more sense to simply leave the "compile this out" >>>> choice up to distributions...? >>> Code rot is a possibility for any code where default is 'n' so that means we should >>> never use it? If that is the case, we should have swap over NFS and Label NFS >>> on be default on by default so those bits don't rote... My point being, I don't >>> think code rot should be a reason for us to maintain code people should not >>> be using in the first place... >> >> In the case at hand, code rot isn't much of a risk if the point is to remove a feature. >> But that point wasn't stated anywhere. >> >>>> I'd like to reduce the risk of the kernel carrying around code that no-one uses or >>>> compiles. If we truly want this off by default everywhere, shouldn't we just >>>> remove it? (Is that the eventual goal?) >>> I would think so. Turn it off and see who screams.. Then get the clue-bat out for >>> for those people that do scream... ;-) They can always turn it back on... >> >> If deprecation is the long-term goal, we ought to have a stated plan that we all >> agree on. We're talking about removing a feature of Linux NFS that has been a >> mainstay for, literally, decades. Make some noise, let people chime in, and publish >> a plan so folks know what to expect. > That was the purpose of this patch... to start the conversation... It's good for Linux to take some leadership here. Thanks! > >> >> We should also document publicly why we think NFSv2 support should go away. Is it a > < significant maintenance burden? Is it a security problem? Who are the stakeholders? > Its mostly maintenances and limited testing resource. I would rather use cycles > to fix/test v4... > >> >>>> Should the server also disable NFSv2 support by default? If not, then why is the >>>> client special in this regard? >>> We have to start somewhere... It was just easier to start with the client. If >>> Bruce is interested in dropping v2 support on the server, I will be more than >>> willing to looking into that... Actually it might just be a nfs-utils only thing... >> >> It feels like we should have a plan for both the server and client. > I'm thinking we could do it separately... I think we need to plan both, at least, whether we execute the plan on the server-side or not. We may find some dependencies between the server and client, or we may identify other requirements for deprecating support on either side. > >> >> You could remove NFSv2 support in nfs-utils on both sides, I would think. Didn't you >> already remove NFSv2 from the mount.nfs command's version negotiation? > Yes, the mount command no longer negotiates down to v2. The -o v2 mount > option still works. > >> >> Deprecating a kernel feature also has a pathway through the staging tree, IIUC. >> Would that be appropriate for NFSv2? It may even be a requirement these days, but >> I'm not sure. > Really? Anybody know what that pathway is? I'm asking now in a private thread. > >> >>>> Finally, if we go with something like this change, does this patch also need to >>>> update the default configurations shipped with the kernel? >>> What "default configurations shipped with the kernel"? Isn't fs/nfs/Kconfig the >>> only place I need to turn it off? >> >> arch/*/configs/*_defconfig >> >> These were not updated when the NFS client was modularized, so they currently do not >> list an explicit CONFIG_NFS_V2 setting. IIUC that means changing Kconfig ought to be >> enough. > Cool... > > steved. >> >>> Thanks for the cycles! >>> >>> steved. >>> >>>> >>>> >>>> On Jul 3, 2013, at 9:04 AM, Steve Dickson <steved@xxxxxxxxxx> wrote: >>>> >>>>> This patch disables the NFS version 2 module from being compile by default. >>>>> >>>>> Signed-off-by: Steve Dickson <steved@xxxxxxxxxx> >>>>> --- >>>>> fs/nfs/Kconfig | 4 ++-- >>>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>>> >>>>> diff --git a/fs/nfs/Kconfig b/fs/nfs/Kconfig >>>>> index 13ca196..6831a01 100644 >>>>> --- a/fs/nfs/Kconfig >>>>> +++ b/fs/nfs/Kconfig >>>>> @@ -32,12 +32,12 @@ config NFS_FS >>>>> config NFS_V2 >>>>> tristate "NFS client support for NFS version 2" >>>>> depends on NFS_FS >>>>> - default y >>>>> + default n >>>>> help >>>>> This option enables support for version 2 of the NFS protocol >>>>> (RFC 1094) in the kernel's NFS client. >>>>> >>>>> - If unsure, say Y. >>>>> + If unsure, say n. >>>>> >>>>> config NFS_V3 >>>>> tristate "NFS client support for NFS version 3" >>>>> -- >>>>> 1.8.1.4 >>>>> >>>>> -- >>>>> 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 >>>> >>> -- >>> 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 >> > -- > 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 -- Chuck Lever chuck[dot]lever[at]oracle[dot]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
