Rustaceans at the border [LWN.net]

Rustaceans at the border

Posted Apr 14, 2022 20:09 UTC (Thu) by mb (subscriber, #50428)
Parent article: Rustaceans at the border

One (IMO) major problem with letting each kernel module choose to fetch random crates from crates.io is that it will result in multiple incompatible versions of the same crate being built into the kernel.

E.g. the module wants foo-1.0 and a dependency of the module wants foo-2.0. And another module requires foo-3.0. Therefore, three versions are included.

The kernel as a whole must agree on which crate versions to use.

to post comments

Rustaceans at the border

Posted Apr 14, 2022 22:23 UTC (Thu) by nybble41 (subscriber, #55106) [Link]

To an extent you'll see that happen anyway when Rust-based modules are compiled separately from the kernel. Rust code compiled for the kernel will be specialized based on how it's used in the kernel, and the same Rust code compiled for a loadable module will be specialized for the module. In Rust that can even affect things like structure layout, unless the structure has been declared #[repr(C)].

In general this isn't a problem so long as you don't try to cross kernel/module boundaries through the (unstable) Rust ABI. The module should expose C entry points and only share #[repr(C)] data with outside code—even other code written in Rust. Even if a module happens to pull in a different version of some dependency than the kernel, the dependency will be constrained to that module and will not affect the rest of the system.

Rustaceans at the border

Posted Apr 15, 2022 19:36 UTC (Fri) by bartoc (guest, #124262) [Link]

You actually don't have to agree on what version to use, since the build system makes sure that you see the definitions you were expecting and everything is mangled such that you can't screw it up.

It is not good to have multiple versions of stuff for other reasons, like code auditing, and code size, and compile time