The readme hints at the prompt:
> It keeps the original system's semantics — what it does — while rethinking how it's expressed: stronger types, clearer module boundaries, idiomatic abstractions everywhere.
"idiomatic abstractions" would certainly bloat the line count.
Sounds like a fun project....
* https://github.com/yuan-xy/Linux-0.11/blob/master/kernel/for...
* https://github.com/Poseidon-fan/linux-0.11-rs/blob/420152fdf...
The Rust is slightly shorter, though it also isn't organized in exactly the same way. The code isn't that different overall, creating and copying some data structures around, as you'd expect for a fork implementation of this vintage.
Maybe I got lucky, but I would expect that it's more of what other people said: this repository includes far more than the kernel.
It's about 15k lines of code for the kernel and the rest is various utilities, libraries and programs that can run on the kernel.
C code probably has no problem mixing and perverting int vs enum. Bitfields, structs, etc…
A rust program would define an enum and also implement handling of unexpected values (or consider them errors). Structs and bitfields would be more intentionally used.
Sure, Rust macros can avoid the boilerplate code, but overall line count may still increase a bit.
That said, I’d blame auto-generated code here as other commenters do.
The majority of Rust the code in the repo is not for the Linux kernel.
Only in extra syntax constructs.
But Rust can absolutely do the same thing as C in fewer lines, especially when comparing each's standard features like string support.
Rust may be verbose, but at least you can read it without turning into a cynical greybeard subject matter expert first.
And the terseness is good when you’re familiar with the code.
Actually stuff like fn, mut etc. feels like mutilation to me. I guess it is highly individual.