> On Oct 25, 2024, at 6:47 PM, Rick Macklem <rick.macklem@xxxxxxxxx> wrote: > > So, I've finally figured out how to use git format-patch. It took > me a lot of tries before I discovered all you do is specify "master.." > to make it work. (I still haven't tried to email them via gmail, but > I've found the doc for that.) > > At this point, the patches are still in need of testing (I have yet to > test the nfsd case where file object creation specifies a POSIX draft > ACL, since neither FreeBSD nor Linux clients do that.) > > Is it time to post the patch sets for others to try or should I wait a while? My only hesitation is that the draft hasn't gone through WGLC yet. The probability of changes to the wire protocol decrease over time, but after WGLC, we can be pretty certain that the protocol is stable and won't get any further changes that might risk interoperability. The client folks might be OK with just a personal draft, which we have now. Maybe we should consider merging this work now and hide it behind a Kconfig option that defaults N. The risk there is that folks not directly involved might enable this anyway, and if the protocol changes, we'd be stuck having to support one or more pre-standard versions. Opening the floor for comments. For now, usually the developer can maintain a public git repo that contains their patches so that others can pull them for testing. You are free to continue posting new versions of the series (with a cover letter that contains a change log). We probably want to see some unit testing (ie, pynfs) but that can be developed separately. > A couple of questions... > The patches currently have a lot of dprintk()s I used for testing. > Should those be removed before posting or left in for now? The usual policy on the server is that dprintk()s that were used for development but have no diagnostic value for users or administrators should be removed before merging. We also don't like to keep dprintk() call sites in hot paths. Observability in hot paths is done with tracepoints, but if you don't want to add those, just leave a comment where you think each tracepoint might be best, and someone can add them later. > They are currently based on linux-6.11.0-rc6 (linux-next of a few > weeks ago). What do you guys do w.r.t. rebasing them? When these are ready to merge, the series should be based on nfsd-next (server side) or the -next branch for the client side (Trond and Anna take every other release, so ask which is preferred). Pull the base branch into your repo and use "git rebase". > There are three sets: common, client and server (common is > needed by both the others. We'll have to decide how these will get merged, as I mentioned to you previously: Either one side goes first and pulls the common branch, then the other side merges later; or one side agrees to pull all three at once. > The other two sets implement client and server side for handling > the new attributes proposed in > https://datatracker.ietf.org/doc/draft-rmacklem-nfsv4-posix-acls/ > > Thanks in advance for any help, rick > ps: The problem I thought I had w.r.t. server side large ACLs does > not appear to be a problem. It also appears that the nfsd always > sets up a scratch buffer, so the server code doesn't do that, either. > -- Chuck Lever
