4 ms·
Why can't all symbols exported to modules maintain a C ABI, obviating (if I understand correctly) the genksyms problem?
by cozzyd 2y ago
Why can't all symbols exported to modules maintain a C ABI, obviating (if I understand correctly) the genksyms problem?
- kelnos 2y agoBecause then when you want to write a module in Rust, all your interfacing with the rest of the kernel will be done through C function calls, with C semantics, and C expectations of ownership. There's really little point to adding Rust abstractions to the kernel, then, at least when it comes to modules.
- cozzyd 2y agoBut without a stable ABI can you expect modules to realistically work across versions? It seems like a similar problem to shared libraries, which rust punts on.
- deleted 2y ago[deleted]
- tasn 2y agoThe kernel doesn't offer a stabke ABI for modules regardless of Rust. So what you're describing is already the case.
- cozzyd 2y agoSure, it changes when something changes, but with rust it changes (in theory) without any code changes but with a tool chain change.
- steveklabnik 2y agoThe point is that there’s no requirement at all, so the rate of change is irrelevant.
- duped 2y ago(by my reading) the problem is that determining what the C ABI is relies on a C parser. If a module depends on an API, genksyms checks if the ABI has changed and won't load the module as a result (or more broadly, it could also use content addressing to look at the body of the function). It seems like the solution is to use DWARF info to determine that but it has to be backwards compatible because previous implementations relied on the parsed C code and not the DWARF symbol info.