Commit Graph

4 Commits

Author SHA1 Message Date
Chuck Lever
4329010ad9 xdrgen: Address some checkpatch whitespace complaints
This is a roll-up of three template fixes that eliminate noise from
checkpatch output so that it's easier to spot non-trivial problems.

To follow conventional kernel C style, when a union declaration is
marked with "pragma public", there should be a blank line between
the emitted "union xxx { ... };" and the decoder and encoder
function declarations.

Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2026-01-26 10:10:58 -05:00
Chuck Lever
6e853dcd2d xdrgen: Rename "enum yada" types as just "yada"
This simplifies the generated C code and makes way for supporting
big-endian XDR enums.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2024-11-11 13:42:00 -05:00
Chuck Lever
c060f8168b xdrgen: Rename enum's declaration Jinja2 template
"close.j2" is a confusing name.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2024-11-11 13:41:59 -05:00
Chuck Lever
4b132aacb0 tools: Add xdrgen
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>
2024-09-20 19:31:39 -04:00