linux-rng/tools/net/sunrpc/xdrgen/generators/program.py, branch master

xdrgen: Share void RPC procedure handlers across programs

2026-08-10T13:54:35Z

The generated server-side decoder and encoder for a void procedure argument or result are named after the RPC program (for example, nfs_svc_decode_void). xdrgen derives that prefix from the program name alone, not the version, so two versions of one program built into the same module emit the identical symbol. NFSv2 and NFSv3 both declare program NFS_PROGRAM; once both are converted, fs/nfsd fails to link with multiple definitions of nfs_svc_decode_void and nfs_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() and xdrgen_svc_encode_void(), in the xdrgen builtins, and stop the program generator from emitting a per-program void handler. lockd is the one in-tree consumer that already emits per-program void handlers, so regenerate the NLMv3 and NLMv4 XDR code to drop nlm_svc_{decode,encode}_void() and nlm4_svc_{decode,encode}_void() and point both procedure tables at the shared handlers. The shared handlers are identical to the generated ones they replace, so no wire behavior changes. Only the server (svc) handlers are affected. The client-side void stubs remain static and per-program, so they do not collide. Link: https://patch.msgid.link/20260712193122.116845-3-cel@kernel.org Signed-off-by: Chuck Lever

xdrgen: Emit a max_arg_sz macro

2026-01-26T15:10:58Z

struct svc_service has a .vs_xdrsize field that is filled in by servers for each of their RPC programs. This field is supposed to contain the size of the largest procedure argument in the RPC program. This value is also sometimes used to size network transport buffers. Currently, server implementations must manually calculate and hard-code this value, which is error-prone and requires updates when procedure arguments change. Update xdrgen to determine which procedure argument structure is largest, and emit a macro with a well-known name that contains the size of that structure. Server code then uses this macro when initializing the .vs_xdrsize field. For NLM version 4, xdrgen now emits: #define NLM4_MAX_ARGS_SZ (NLM4_nlm4_lockargs_sz) Signed-off-by: Chuck Lever

xdrgen: Emit the program number definition

2026-01-26T15:10:58Z

"xdrgen definitions" was not providing a definition of a symbolic constant for the RPC program number being defined. Signed-off-by: Chuck Lever

xdrgen: Prevent reordering of encoder and decoder functions

2024-09-20T23:31:41Z

I noticed that "xdrgen source" reorders the procedure encoder and decoder functions every time it is run. I would prefer that the generated code be more deterministic: it enables a reader to better see exactly what has changed between runs of the tool. The problem is that Python sets are not ordered. I use a Python set to ensure that, when multiple procedures use a particular argument or result type, the encoder/decoder for that type is emitted only once. Sets aren't ordered, but I can use Python dictionaries for this purpose to ensure the procedure functions are always emitted in the same order if the .x file does not change. Signed-off-by: Chuck Lever

tools: Add xdrgen

2024-09-20T23:31:39Z

Add a Python-based tool for translating XDR specifications into XDR encoder and decoder functions written in the Linux kernel's C coding style. The generator attempts to match the usual C coding style of the Linux kernel's SunRPC consumers. This approach is similar to the netlink code generator in tools/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 code In addition, converting the XDR layer to use memory-safe languages such as Rust will be easier if much of the code can be converted automatically. Tested-by: Jeff Layton Signed-off-by: Chuck Lever