summaryrefslogtreecommitdiff
path: root/tools/net/sunrpc/xdrgen/generators
AgeCommit message (Collapse)Author
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: Implement big-endian enumsChuck Lever
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2024-11-11xdrgen: Rename enum's declaration Jinja2 templateChuck Lever
"close.j2" is a confusing name. 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: Prevent reordering of encoder and decoder functionsChuck Lever
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 <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>