summaryrefslogtreecommitdiff
path: root/tools/net/sunrpc/xdrgen/templates/C/pointer
AgeCommit message (Collapse)Author
2025-05-16xdrgen: Fix code generated for counted arraysChuck Lever
When an XDR counted array has a maximum element count, xdrgen adds a bounds check to the encoder or decoder for that type. But in cases where the .x provides no maximum element count, such as struct notify4 { /* composed from notify_type4 or notify_deviceid_type4 */ bitmap4 notify_mask; notifylist4 notify_vals; }; struct CB_NOTIFY4args { stateid4 cna_stateid; nfs_fh4 cna_fh; notify4 cna_changes<>; }; xdrgen is supposed to omit that bounds check. Some of the Jinja2 templates handle that correctly, but a few are incorrect and leave the bounds check in place with a maximum of zero, which causes encoding/decoding of that type to fail unconditionally. Reported-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2024-11-11xdrgen: Add generator code for XDR width macrosChuck Lever
Introduce logic in the code generators to emit maxsize (XDR width) definitions. In C, these are pre-processor macros. Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2024-11-11xdrgen: Rename "variable-length strings"Chuck Lever
I misread RFC 4506. The built-in data type is called simply "string", as there is no fixed-length variety. Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2024-09-20xdrgen: Fix return code checking in built-in XDR decodersChuck Lever
xdr_stream_encode_u32() returns XDR_UNIT on success. xdr_stream_decode_u32() returns zero or -EMSGSIZE, but never XDR_UNIT. Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2024-09-20tools: Add xdrgenChuck Lever
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 <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>