How many % of the kernel is Rust now, in terms of LoC?
The Linux Kernel Prepares for Rust 1.77 Upgrade
21–30 of 107 posts
Re: The Linux Kernel Prepares for Rust 1.77 Upgrade
#22Rust is going to kill LFS
Re: The Linux Kernel Prepares for Rust 1.77 Upgrade
#23Re: The Linux Kernel Prepares for Rust 1.77 Upgrade
#24The LKM post mentions binary size improvements. One issues I have had with Rust applications is the huge binary size (yes, I know this has improved a bit lately). Is there a good comparison between kernel C and kernel Rust code in this regard?
So one issue I can imagine being the culprit with rust is the specializing / c++ style semantics of rust generics. C code generics tend to be void* flavored or point to a struct of function pointers. Which will generate less code. Not sure how this translates to the kernel setting thoughb
However, most complaints are about size of “Hello World”, which in Rust is due to libstd always having debug info (to be fixed soon), and panic handling code that includes backtrace printing (because print to stdout can fail).
Printing of backtrace is very bloaty, because it parses and decompresses debug info.
Re: The Linux Kernel Prepares for Rust 1.77 Upgrade
#25Earlier quoted context omitted.
Most size issues come from not using release builds, using too many dependencies, or overuse of generics. The rust std lib being linked in statically also contributes.The kernel shouldn't suffer from any of these problems. Plenty of embedded use is able to use rust in highly constrained environments without size issues compared to C.
Saying part of the problem is “using too many dependencies” is not an overly helpful thing if the ecosystem keeps on trying to download 3Gb of build dependencies because you tried to use some simple little library. The problem is obvious, it’s the solution that is much more difficult.
Re: The Linux Kernel Prepares for Rust 1.77 Upgrade
#26The LKM post mentions binary size improvements. One issues I have had with Rust applications is the huge binary size (yes, I know this has improved a bit lately). Is there a good comparison between kernel C and kernel Rust code in this regard?
Another thing just to mention here is `strip`, which IIRC `cargo build --release` doesn't do by default. I think `stripping` binaries can reduce binary size by up to 80-85% in some cases (but certainly not all; just tried it locally on a 1M rust binary and got 40% reduction). FWIW, you can configure this in Cargo.toml: [profile.release] strip = true
Re: The Linux Kernel Prepares for Rust 1.77 Upgrade
#27Do I understand it correctly that upgrading to a new rust version is mostly implementing new best practices and new features, instead of needing to "fix" your code, as rust is backwards compatible? I've only used rust nightly for my own projects and didn't give too much thought about rust versions
Re: The Linux Kernel Prepares for Rust 1.77 Upgrade
#28Earlier quoted context omitted.
Saying part of the problem is “using too many dependencies” is not an overly helpful thing if the ecosystem keeps on trying to download 3Gb of build dependencies because you tried to use some simple little library. The problem is obvious, it’s the solution that is much more difficult.
> if the ecosystem keeps on trying to download 3Gb of build dependencies because you tried to use some simple little library. Downloading 3GB of dependencies is not a thing that happens in the Rust ecosystem. Reality is orders of magnitude smaller than that. Why are you exaggerating so much? Some people bristle at the thought of external dependencies, but if you want to do common tasks it makes sense to pull in commo…
Re: The Linux Kernel Prepares for Rust 1.77 Upgrade
#29Do I understand it correctly that upgrading to a new rust version is mostly implementing new best practices and new features, instead of needing to "fix" your code, as rust is backwards compatible? I've only used rust nightly for my own projects and didn't give too much thought about rust versions