Changes in string.j2

c771600c6af14749609b49565ffb4cac2959710d - Merge drm/drm-next into drm-intel-gt-next

Wed, 05 Feb 2025 09:29:14 +0000

Merge drm/drm-next into drm-intel-gt-nextWe need4ba4f1afb6a9 ("perf: Generic hotplug support for a PMU with a scope")in order to land a i915 PMU simplification and a fix. That landed in 6.12and we are stuck at 6.9 so lets bump things forward.Signed-off-by: Tvrtko Ursulin List of files: /linux/tools/net/sunrpc/xdrgen/templates/C/pointer/decoder/string.j2

041962d5c6a965f1a6c338be49acfe7ab51d2056 - xdrgen: Rename "variable-length strings"

Mon, 30 Sep 2024 00:50:13 +0000

xdrgen: Rename "variable-length strings"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 List of files: /linux/tools/net/sunrpc/xdrgen/templates/C/pointer/decoder/string.j2

4b132aacb0768ac1e652cf517097ea6f237214b9 - tools: Add xdrgen

Fri, 13 Sep 2024 18:08:13 +0000

tools: Add xdrgenAdd a Python-based tool for translating XDR specifications into XDRencoder and decoder functions written in the Linux kernel's C codingstyle. The generator attempts to match the usual C coding style ofthe Linux kernel's SunRPC consumers.This approach is similar to the netlink code generator intools/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 codeIn addition, converting the XDR layer to use memory-safe languagessuch as Rust will be easier if much of the code can be convertedautomatically.Tested-by: Jeff Layton Signed-off-by: Chuck Lever List of files: /linux/tools/net/sunrpc/xdrgen/templates/C/pointer/decoder/string.j2