aboutsummaryrefslogtreecommitdiffstats
path: root/tools/net/sunrpc
Commit message (Collapse)AuthorAgeFilesLines
* sunrpc: Change ret code of xdr_stream_decode_opaque_fixedSergey Bashirov2025-09-211-1/+1
| | | | | | | | | | | | | | Since the opaque is fixed in size, the caller already knows how many bytes were decoded, on success. Thus, xdr_stream_decode_opaque_fixed() doesn't need to return that value. And, xdr_stream_decode_u32 and _u64 both return zero on success. This patch simplifies the caller's error checking to avoid potential integer promotion issues. Suggested-by: Dan Carpenter <[email protected]> Signed-off-by: Sergey Bashirov <[email protected]> Signed-off-by: Chuck Lever <[email protected]>
* xdrgen: Fix code generated for counted arraysChuck Lever2025-05-163-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]> Signed-off-by: Chuck Lever <[email protected]>
* xdrgen: Remove program_stat_to_errno() call sitesChuck Lever2024-11-191-2/+0
| | | | | | | Refactor: Translating an on-the-wire value to a local host errno is architecturally a job for the proc function, not the XDR decoder. Signed-off-by: Chuck Lever <[email protected]>
* xdrgen: Update the files included in client-side source codeChuck Lever2024-11-191-2/+7
| | | | | | | | In particular, client-side source code needs the definition of "struct rpc_procinfo" and does not want header files that pull in "struct svc_rqst". Otherwise, the source does not compile. Signed-off-by: Chuck Lever <[email protected]>
* xdrgen: Remove check for "nfs_ok" in C templatesChuck Lever2024-11-191-1/+1
| | | | | | | Obviously, "nfs_ok" is defined only for NFS protocols. Other XDR protocols won't know "nfs_ok" from Adam. Signed-off-by: Chuck Lever <[email protected]>
* xdrgen: Remove tracepoint call siteChuck Lever2024-11-191-3/+1
| | | | | | | | | This tracepoint was a "note to self" and is not operational. It is added only to client-side code, which so far we haven't needed. It will cause immediate breakage once we start generating client code, though, so remove it now. Signed-off-by: Chuck Lever <[email protected]>
* xdrgen: Add a utility for extracting XDR from RFCsChuck Lever2024-11-191-0/+11
| | | | | | | For convenience, copy the XDR extraction script from RFC Reviewed-by: Jeff Layton <[email protected]> Signed-off-by: Chuck Lever <[email protected]>
* xdrgen: emit maxsize macrosChuck Lever2024-11-112-5/+22
| | | | | | | Add "definitions" subcommand logic to emit maxsize macros in generated code. Signed-off-by: Chuck Lever <[email protected]>
* xdrgen: Add generator code for XDR width macrosChuck Lever2024-11-1115-6/+107
| | | | | | | Introduce logic in the code generators to emit maxsize (XDR width) definitions. In C, these are pre-processor macros. Signed-off-by: Chuck Lever <[email protected]>
* xdrgen: XDR width for union typesChuck Lever2024-11-111-0/+26
| | | | | | | | | | | | | | | Not yet complete. The tool doesn't do any math yet. Thus, even though the maximum XDR width of a union is the width of the union enumerator plus the width of its largest arm, we're using the sum of all the elements of the union for the moment. This means that buffer size requirements are overestimated, and that the generated maxsize macro cannot yet be used for determining data element alignment in the XDR buffer. Signed-off-by: Chuck Lever <[email protected]>
* xdrgen: XDR width for pointer typesChuck Lever2024-11-111-0/+17
| | | | | | | | The XDR width of a pointer type is the sum of the widths of each of the struct's fields, except for the last field. The width of the implicit boolean "value follows" field is added as well. Signed-off-by: Chuck Lever <[email protected]>
* xdrgen: XDR width for struct typesChuck Lever2024-11-111-0/+16
| | | | | | | The XDR width of a struct type is the sum of the widths of each of the struct's fields. Signed-off-by: Chuck Lever <[email protected]>
* xdrgen: XDR width for typedefChuck Lever2024-11-111-7/+27
| | | | | | The XDR width of a typedef is the same as the width of the base type. Signed-off-by: Chuck Lever <[email protected]>
* xdrgen: XDR width for optional_data typeChuck Lever2024-11-111-0/+10
| | | | Signed-off-by: Chuck Lever <[email protected]>
* xdrgen: XDR width for variable-length arrayChuck Lever2024-11-111-0/+16
| | | | Signed-off-by: Chuck Lever <[email protected]>
* xdrgen: XDR width for fixed-length arrayChuck Lever2024-11-111-0/+13
| | | | Signed-off-by: Chuck Lever <[email protected]>
* xdrgen: XDR width for a stringChuck Lever2024-11-111-0/+15
| | | | | | | A string works like a variable-length opaque. See Section 4.11 of RFC 4506. Signed-off-by: Chuck Lever <[email protected]>
* xdrgen: XDR width for variable-length opaqueChuck Lever2024-11-111-0/+15
| | | | | | | | The byte size of a variable-length opaque is conveyed in an unsigned integer. If there is a specified maximum size, that is included in the type's widths list. Signed-off-by: Chuck Lever <[email protected]>
* xdrgen: XDR width for fixed-length opaqueChuck Lever2024-11-111-0/+22
| | | | | | | The XDR width for a fixed-length opaque is the byte size of the opaque rounded up to the next XDR_UNIT, divided by XDR_UNIT. Signed-off-by: Chuck Lever <[email protected]>
* xdrgen: XDR widths for enum typesChuck Lever2024-11-111-0/+12
| | | | | | | RFC 4506 says that an XDR enum is represented as a signed integer on the wire; thus its width is 1 XDR_UNIT. Signed-off-by: Chuck Lever <[email protected]>
* xdrgen: Keep track of on-the-wire data type widthsChuck Lever2024-11-111-0/+43
| | | | | | | | | | | | | | | The generic parts of the RPC layer need to know the widths (in XDR_UNIT increments) of the XDR data types defined for each protocol. As a first step, add dictionaries to keep track of the symbolic and actual maximum XDR width of XDR types. This makes it straightforward to look up the width of a type by its name. The built-in dictionaries are pre-loaded with the widths of the built-in XDR types as defined in RFC 4506. Signed-off-by: Chuck Lever <[email protected]>
* xdrgen: Track constant valuesChuck Lever2024-11-111-0/+10
| | | | | | | | | In order to compute the numeric on-the-wire width of XDR types, xdrgen needs to keep track of the numeric value of constants that are defined in the input specification so it can perform calculations with those values. Signed-off-by: Chuck Lever <[email protected]>
* xdrgen: Refactor transformer armsChuck Lever2024-11-111-24/+33
| | | | | | | Clean up: Add a __post_init__ function to the data classes that need to update the "structs" and "pass_by_reference" sets. Signed-off-by: Chuck Lever <[email protected]>
* xdrgen: Implement big-endian enumsChuck Lever2024-11-1110-14/+96
| | | | Signed-off-by: Chuck Lever <[email protected]>
* xdrgen: Rename "enum yada" types as just "yada"Chuck Lever2024-11-115-8/+5
| | | | | | | This simplifies the generated C code and makes way for supporting big-endian XDR enums. Signed-off-by: Chuck Lever <[email protected]>
* xdrgen: Rename enum's declaration Jinja2 templateChuck Lever2024-11-112-1/+1
| | | | | | "close.j2" is a confusing name. Signed-off-by: Chuck Lever <[email protected]>
* xdrgen: Rename "variable-length strings"Chuck Lever2024-11-1116-19/+19
| | | | | | | 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 <[email protected]>
* xdrgen: Clean up type_specifierChuck Lever2024-11-111-2/+2
| | | | | | | Clean up: Make both arms of the type_specifier AST transformer match. No behavior change is expected. Signed-off-by: Chuck Lever <[email protected]>
* xdrgen: Exit status should be zero on successChuck Lever2024-11-111-1/+3
| | | | | | | | To use xdrgen in Makefiles, it needs to exit with a zero status if the compilation worked. Otherwise the make command fails with an error. Signed-off-by: Chuck Lever <[email protected]>
* xdrgen: Prevent reordering of encoder and decoder functionsChuck Lever2024-09-201-12/+12
| | | | | | | | | | | | | | | | | 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 <[email protected]>
* xdrgen: typedefs should use the built-in string and opaque functionsChuck Lever2024-09-202-2/+2
| | | | | | | 'typedef opaque yada<XYZ>' should use xdrgen's built-in opaque encoder and decoder, to enable better compiler optimization. Signed-off-by: Chuck Lever <[email protected]>
* xdrgen: Fix return code checking in built-in XDR decodersChuck Lever2024-09-203-3/+3
| | | | | | | | 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 <[email protected]>
* tools: Add xdrgenChuck Lever2024-09-20151-0/+3927
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 <[email protected]> Signed-off-by: Chuck Lever <[email protected]>
generated by cgit (git 2.51.2) at 2025-12-02 22:34:13 +0000