> So, even if you enable CONFIG_MODVERSIONS, > nothing is checked for Rust. > Genksyms computes a CRC from "int foo", and > the module subsystem confirms it is a "int" > variable. > > We know this check always succeeds. > > Why is this useful? The reason this is immediately useful is that it allows us to have Rust in use with a kernel where C modules are able to benefit from MODVERSIONS checking. The check would effectively be a no-op for now, as you have correctly determined, but we could refine it to make it more restrictive later. Since the existing C approach errs on the side of "it could work" rather than "it will work", I thought being more permissive was the correct initial solution. If we want to err on the other side (modversions passes, so we're pretty sure it will work), I could add to the last patch support for using .rmeta files as the CRC source for Rust symbols. This would essentially say that the interface for the entire compilation unit has to stay the same rather than just that one function. We could potentially loosen this requirement in the future. With regards to future directions that likely won't work for loosening it: Unfortunately, the .rmeta format itself is not stable, so I wouldn't want to teach genksyms to open it up and split out the pieces for specific functions. Extending genksyms to parse Rust would also not solve the situation - layouts are allowed to differ across compiler versions or even (in rare cases) seemingly unrelated code changes. Future directions that might work for loosening it: * Generating crcs from debuginfo + compiler + flags * Adding a feature to the rust compiler to dump this information. This is likely to get pushback because Rust's current stance is that there is no ability to load object code built against a different library. Would setting up Rust symbols so that they have a crc built out of .rmeta be sufficient for you to consider this useful? If not, can you help me understand what level of precision would be required?
