I’ve done some experiments with replacing the python scripts with rust tools,
The gist of it was:
- Have a library crate which does the parsing
- The tools then link to that crate, for code generation
- Both tools and libraries, get compiled for and run on the host system as part of the kernel build.
The hope was that by separating out xml parsing from code-gen, the code generation would be easier to maintain…
This was described in the thread I posted here: but I probably have done a terrible job of trying to explain, how it works in the thread I created for this is here (so I guess I should try again):
There is a small patch to the kernel build scripts that adds an empty kernel/external directory, and recurses calling add_subdirectory for each subdirectory of kernel/external, (basically each subdirectory is assumed to have CMakeLists.txt)
The manifest
links in the libraries/tools and a cmake script which depends/runs them, this triggers everything to get built, then run.
With this setup it is entirely possible to link in the library, and swap in your own tools that depend upon the library which does the parsing code, and replace the cmake script to run your own tools
I wouldn’t say it is exactly straight forward with the code generation, cmake stuff calling the generators, and manifests linking them spread out across repositories, but it does at least give a high level library interface to the contents of the xml API which can be reused for various purposes.
It contains an existing port of the python c code-gen, which could eventually be used with e.g. CI to compare the output to the python generated code.