On Wed, Jun 19, 2024 at 06:04:46PM +0000, Chuck Lever III wrote: > > > > On Jun 19, 2024, at 1:57 PM, Mike Snitzer <snitzer@xxxxxxxxxx> wrote: > > > > On Wed, Jun 19, 2024 at 05:10:10PM +1000, NeilBrown wrote: > >> On Wed, 19 Jun 2024, Christoph Hellwig wrote: > >>> What happened to the requirement that all protocol extensions added > >>> to Linux need to be standardized in IETF RFCs? > >>> > >>> > >> > >> Is that requirement documented somewhere? Not that I doubt it, but it > >> would be nice to know where it is explicit. I couldn't quickly find > >> anything in Documentation/ > >> > >> Can we get by without the LOCALIO protocol? > >> > >> For NFSv4.1 we could use the server_owner4 returned by EXCHANGE_ID. It > >> is explicitly documented as being usable to determine if two servers are > >> the same. > > > > My first approach was to (ab)use EXCHANGE_ID. It worked, but it > > required exporting a symbol to query the hash table local to > > nfs4state, etc. It wasn't very clean.. could it have been made > > clean?: I guess... but in the end I elected to solve both v3 and v4.x in > > the same way using LOCALIO protocol. > > > >> For NFSv4.0 ... I don't think we should encourage that to be used. > >> > >> For NFSv3 it is harder. I'm not as ready to deprecate it as I am for > >> 4.0. There is nothing in NFSv3 or MOUNT or NLM that is comparable to > >> server_owner4. If krb5 was used there would probably be a server > >> identity in there that could be used. > >> I think the server could theoretically return an AUTH_SYS verifier in > >> each RPC reply and that could be used to identify the server. I'm not > >> sure that is a good idea though. > >> > >> Going through the IETF process for something that is entirely private to > >> Linux seems a bit more than should be necessary.. > > > > I have to believe Christoph didn't appreciate this LOCALIO protocol is > > an entirely private implementation detail to Linux (that allows client > > and server handshake). I've clarified that in Documentation (for v6). > > Even though this is a private protocol, you don't want some > other NFS implementation re-using that RPC program number > for its own purposes. > > I think registering the RPC program number and name with > IANA is going to save everyone some potential headaches > and won't be an arduous process. I fully agree, I will work on it. If you have hints for the best place to start I'd welcome any help getting the process started. In v6 I switch to using rpc program number 0x20000002
