All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bruce Fields <bfields@fieldses.org>
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH RFC 4/8] NFSD: Refactor NFSv3 CREATE
Date: Thu, 21 Apr 2022 12:37:39 -0400	[thread overview]
Message-ID: <20220421163739.GA18620@fieldses.org> (raw)
In-Reply-To: <D7DC153B-F946-46EA-9A02-B29B0FE6EDC4@oracle.com>

On Wed, Apr 20, 2022 at 07:31:09PM +0000, Chuck Lever III wrote:
> > I wonder if it'd be
> > possible to keep the two paths free of complications from each other
> > while sharing more code, e.g. if there are logical blocks of code that
> > could now be pulled out into common helpers.
> 
> I'm open to suggestions, but after the final patch in this
> series, I don't see much else that is meaningful that can be
> re-used by both. nfsd_create_setattr() was the one area that
> seemed both common and heavyweight. The other areas are just
> lightweight sanity checks.
> 
> And honestly, in this case, I don't think these code paths
> are well-served by aggressive code de-duplication. The code
> in each case is more readable and less brittle this way. The
> NFSv4 code path now has some comments that mark the subtle
> differences with NFSv3 exclusive create, and now you can't
> break NFSv3 CREATE by making a change to NFSv4 OPEN, which
> is far more complex.

I can live with that.

Also, this passes all my usual regression tests, FWIW.

--b.

  reply	other threads:[~2022-04-21 16:37 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-20 18:28 [PATCH RFC 0/8] Make NFSv4 OPEN(CREATE) less brittle Chuck Lever
2022-04-20 18:28 ` [PATCH RFC 1/8] NFSD: Clean up nfsd3_proc_create() Chuck Lever
2022-04-20 18:28 ` [PATCH RFC 2/8] NFSD: Avoid calling fh_drop_write() twice in do_nfsd_create() Chuck Lever
2022-04-20 18:28 ` [PATCH RFC 3/8] NFSD: Refactor nfsd_create_setattr() Chuck Lever
2022-04-20 18:29 ` [PATCH RFC 4/8] NFSD: Refactor NFSv3 CREATE Chuck Lever
2022-04-20 19:10   ` J. Bruce Fields
2022-04-20 19:31     ` Chuck Lever III
2022-04-21 16:37       ` Bruce Fields [this message]
2022-04-20 18:29 ` [PATCH RFC 5/8] NFSD: Refactor NFSv4 OPEN(CREATE) Chuck Lever
2022-04-20 18:29 ` [PATCH RFC 6/8] NFSD: Remove do_nfsd_create() Chuck Lever
2022-04-20 18:29 ` [PATCH RFC 7/8] NFSD: Clean up nfsd_open_verified() Chuck Lever
2022-04-20 18:29 ` [PATCH RFC 8/8] NFSD: Instantiate a struct file when creating a regular NFSv4 file Chuck Lever
2022-04-20 19:24 ` [PATCH RFC 0/8] Make NFSv4 OPEN(CREATE) less brittle 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=20220421163739.GA18620@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=chuck.lever@oracle.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.