linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steve Dickson <SteveD@redhat.com>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Bryan Schumaker <bjschuma@netapp.com>, linux-nfs@vger.kernel.org
Subject: Re: [RFC 0/4] NFS: Modularize NFS v3
Date: Thu, 01 Dec 2011 21:38:43 -0500	[thread overview]
Message-ID: <4ED83A33.7030607@RedHat.com> (raw)
In-Reply-To: <1322776630.4711.37.camel@lade.trondhjem.org>



On 12/01/2011 04:57 PM, Trond Myklebust wrote:
> On Thu, 2011-12-01 at 16:55 -0500, Bryan Schumaker wrote: 
>> On Thu Dec  1 16:05:03 2011, Steve Dickson wrote:
>>>
>>>
>>> On 12/01/2011 11:48 AM, bjschuma@netapp.com wrote:
>>>> From: Bryan Schumaker <bjschuma@netapp.com>
>>>>
>>>> This set of patches removes NFS v3 from the main NFS kernel module and creates
>>>> a new module containing the proc, xdr, and acl code.  This will give us a
>>>> single directory to put NFS v3 specific code so it doesn't need to be mixed in
>>>> with the generic client stuff.
>>>>
>>>> I'm sure this could still use a lot of work, but I figured I would wait to see
>>>> what everybody thinks first.  I imagine that once we get an "nfs submodule"
>>>> system working it'll be easier to convert v2 and v4 (and possibly v4.1?) to
>>>> modules.
>>>>
>>>> I split the second patch into two to make it easier to see what my changes were
>>>> to get everything to compile.  Hopefully this will save some pain in having to
>>>> look through 7000+ line patch that resulted from my `mv nfs3*.c nfs3/`
>>>> command.  I can combine everything in a future version of the patch.
>>>>
>>>> v2:
>>>>   - I set the "diff.renames copy" git config option to create a smaller second
>>>>     patch.  Maybe this time it won't get me kicked off the mailing list...
>>>>     Thanks to Boaz and Jim for the tip!
>>>>
>>>> Thoughts?
>>> Now what is the motivating reason behind this re-architecture
>>> other than making the upstream kernel literally impossible to 
>>> back port to older kernels?? 
>>>
>> I wasn't thinking about backporting when I did this... is there a 
>> better way to do this that wouldn't make it a pain to backport?
>>
>> My thought was that it would help clean things up a bit by adding a bit 
>> of separation between the nfs client and each nfs protocol.  It would 
>> also allow user to decide what they need at run time rather than at 
>> compile time.
> 
> It would also be nice to do the same for NFSv2 next. Then maybe we can
> tackle NFSv4...
Why? Just for legacy reasons... why not just leave the v2/v3 support
in the nfs module and break out the v4 code in its own module. 
Have a module called nfsv4. Possibly have different modules for 
different v4 versions... even layer the modules... 

Start with a nfsv4 module. Then have a nfsv41 which is depend on 
the nfsv4 module. Then a nfsv42 module which depend on a nfsv41 
module, etc...  

I'm guessing this push to modularize the code is to make it easier
to eventually stop supporting older protocol version like v2 and
v3... which is understandable... but v2/v3 code is the legacy code..
Why not just remove the old from the new, which, at the end of the
day, would make it easier to maintain the legacy code... IMHO...

steved.


  reply	other threads:[~2011-12-02  2:38 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-01 16:48 [RFC 0/4] NFS: Modularize NFS v3 bjschuma
2011-12-01 16:48 ` [RFC v2 1/4] NFS: Export symbols needed by an NFS v3 module bjschuma
2011-12-01 16:48 ` [RFC v2 2/4] NFS: Move the NFS v3 code into its own subdirectory bjschuma
2011-12-01 16:48 ` [RFC v2 3/4] NFS: Add functions for adding new NFS versions bjschuma
2011-12-01 16:48 ` [RFC v2 4/4] NFS: Turn NFS v3 into a module bjschuma
2011-12-01 17:36 ` [RFC 0/4] NFS: Modularize NFS v3 Jim Rees
2011-12-01 19:56   ` Bryan Schumaker
2011-12-01 21:05 ` Steve Dickson
2011-12-01 21:55   ` Bryan Schumaker
2011-12-01 21:57     ` Trond Myklebust
2011-12-02  2:38       ` Steve Dickson [this message]
2011-12-02  2:01     ` Steve Dickson
2011-12-02 16:24       ` J. Bruce Fields
2012-01-10 17:42 ` Stanislav Kinsbursky
2012-01-10 17:58   ` Bryan Schumaker
  -- strict thread matches above, loose matches on Subject: below --
2011-11-22 22:57 bjschuma
2011-11-23  2:19 ` Boaz Harrosh
2011-11-23  2:41   ` Jim Rees
2011-11-28 14:14     ` Bryan Schumaker
2011-11-23 18:27 ` J. Bruce Fields

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ED83A33.7030607@RedHat.com \
    --to=steved@redhat.com \
    --cc=Trond.Myklebust@netapp.com \
    --cc=bjschuma@netapp.com \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).