> On Apr 20, 2022, at 3:10 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > On Wed, Apr 20, 2022 at 02:29:00PM -0400, Chuck Lever wrote: >> The NFSv3 CREATE and NFSv4 OPEN(CREATE) use cases are about to >> diverge such that it makes sense to split do_nfsd_create() into one >> version for NFSv3 and one for NFSv4. >> >> As a first step, copy do_nfsd_create() to nfs3proc.c and remove >> NFSv4-specific logic. >> >> One immediate legibility benefit is that the logic for handling >> NFSv3 createhow is now quite straightforward. NFSv4 createhow >> has some subtleties that IMO do not belong in generic code. > > That makes sense to me, though just eyeballing the two resulting > functions, you end up with a *lot* of duplication. About 200 lines. I would feel a little more agreeable to this if we didn't already have a separate "create" function for NFSv2 (ie, nfsd_proc_create). > 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. -- Chuck Lever
