xdrgen: Share void RPC procedure handlers across programsThe generated server-side decoder and encoder for a void procedureargument or result are named after the RPC program (for example,nfs_svc_
xdrgen: Share void RPC procedure handlers across programsThe generated server-side decoder and encoder for a void procedureargument or result are named after the RPC program (for example,nfs_svc_decode_void). xdrgen derives that prefix from the programname alone, not the version, so two versions of one program builtinto the same module emit the identical symbol. NFSv2 and NFSv3both declare program NFS_PROGRAM; once both are converted, fs/nfsdfails to link with multiple definitions of nfs_svc_decode_void andnfs_svc_encode_void.A void handler carries no program- or version-specific behavior:each merely forwards to xdrgen_decode_void() or xdrgen_encode_void().Define one shared pair, xdrgen_svc_decode_void() andxdrgen_svc_encode_void(), in the xdrgen builtins, and stop theprogram generator from emitting a per-program void handler.lockd is the one in-tree consumer that already emits per-programvoid handlers, so regenerate the NLMv3 and NLMv4 XDR code to dropnlm_svc_{decode,encode}_void() and nlm4_svc_{decode,encode}_void()and point both procedure tables at the shared handlers. The sharedhandlers are identical to the generated ones they replace, so nowire behavior changes.Only the server (svc) handlers are affected. The client-side voidstubs remain static and per-program, so they do not collide.Link: https://patch.msgid.link/20260712193122.116845-3-cel@kernel.orgSigned-off-by: Chuck Lever <cel@kernel.org>
show more ...
xdrgen: Fix struct prefix for typedef types in program wrappersThe program templates for decoder/argument.j2 and encoder/result.j2unconditionally add 'struct' prefix to all types. This is incorrec
xdrgen: Fix struct prefix for typedef types in program wrappersThe program templates for decoder/argument.j2 and encoder/result.j2unconditionally add 'struct' prefix to all types. This is incorrectwhen an RPC protocol specification lists a typedef'd basic type oran enum as a procedure argument or result (e.g., NFSv2's fhandle orstat), resulting in compiler errors when building generated C code.Fixes: 4b132aacb076 ("tools: Add xdrgen")Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
tools: Add xdrgenAdd a Python-based tool for translating XDR specifications into XDRencoder and decoder functions written in the Linux kernel's C codingstyle. The generator attempts to match the
tools: Add xdrgenAdd a Python-based tool for translating XDR specifications into XDRencoder and decoder functions written in the Linux kernel's C codingstyle. The generator attempts to match the usual C coding style ofthe Linux kernel's SunRPC consumers.This approach is similar to the netlink code generator intools/net/ynl .The maintainability benefits of machine-generated XDR code include:- Stronger type checking- Reduces the number of bugs introduced by human error- Makes the XDR code easier to audit and analyze- Enables rapid prototyping of new RPC-based protocols- Hardens the layering between protocol logic and marshaling- Makes it easier to add observability on demand- Unit tests might be built for both the tool and (automatically) for the generated codeIn addition, converting the XDR layer to use memory-safe languagessuch as Rust will be easier if much of the code can be convertedautomatically.Tested-by: Jeff Layton <jlayton@kernel.org>Signed-off-by: Chuck Lever <chuck.lever@oracle.com>