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... > > 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... > > 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? > >>> 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
