Conversation

Must not make a comparison. Really. Must not. But just saying...

Clang Built Linux took literally years of effort. And it's all still C, just a different compiler.

Did anyone really expect Rust for Linux to be a breeze?

I know, I know, apples and oranges.

4
2
3
@jani luckily all the discussion around this is honest, constructive and calm!
0
0
3

@jani the same folks that pushed backed against clang will be the same ones that complain there is only one rust compiler and we should wait for gcc-rs because only having one compiler is risky 🙂

0
2
0
@jani I look mainly at the data. Firefox at 20% (2017-2024) now. Based on that my rough guess would be that within 5-7 years timeline we have 20% * 0.1 (complexity factor out of top of my head) = 2% of code that is in some defconfig. That is probably also about the time needed to GCC-Rust to catch up, which is literally a hard constraint because a defconfig's need to compile only with a GCC toolchain.

I don't think making Linux clang only would ever receive a positive response. Why I see defconfig level adoption happening in a longer timeline is that in input validation and all kinds of syscall/uapi layer stuff Rust adoption would have undebatable benefits.

I believe I have fairly weighted argument. I've used professionally Rust in user space code since 2022 (and actual low-level stuff like memory manager for Intel SGX enclaves), which I believe gives some basis also for my guess.

Like AI, blockchains, pick-your-hype-tech it is IMHO both uneducated to say that they are a hoax, and also that they solve every possible problem.
1
0
0
@jani Because I'm idealist let's put my 5-7 year timeline guess to 2-5% ;-) As GCC-Rust starts to catch up that might give a boost that is hard to predict beforehand, and also because Firefox is quite distant comparison point.
1
0
0
Edited 10 months ago
Here's something I don't understand: ext2 driver in Rust. Frankly, I just don't get why Microsoft spends money on stuff like that.

Ok, so here's something I WOULD get (assuming that it compiles with GCC because it is a hard constraint): re-write user space interaction points of ext4 driver in Rust and make it call the existing internals.

Then I'd have a patch at hand that is written in Rust and that makes a modest improvement for the sake of better security, i.e. something I can *measure*.

I really try to avoid thinking of liking or disliking patch. If I can measure an improvement that overrides the possible drawbacks, then I see no other choice than carry the patch forward.
1
0
0

@jarkko how can you measure security improvement?

1
0
0

@jani It's a good comparison because IMHO it demonstrates that the path to success is just doing the work. Even when it's slow and grinding and unglamorous.

And to be clear I think the R4L folks have been doing exactly that.

0
0
0
@TheStroyer If that was a generic question I expect a generic answer to the question "how can you measure performance" before answering that.

In the context Rust would provide vastly better static checks for input validation in the uapi 🤷 Uapi is also part of the kernel, which would not require extensive use unsafe blocks in Rust when compared to e.g. something like mm. Obviously this is not universal truth but instead depends on case by case. For instance reading any kind of structure data (including binary not just text) the benefits are obvious.
1
0
0

@jarkko well, you seem to imply that it's possible to easily measure security improvements by rewriting the ext4 user space interface in rust.
But how do you measure that? By the amount of unsafe code blocks? Something being "safe" code in rust doesn't mean it doesn't contain any security vulnerabilities. So I wonder how you would show it in a way that is so obvious as to make it impossible to deny the patch

1
0
0
@TheStroyer Those are your own interpretations, please do not put words to my mouth :-) I answered already all I want to say on this, thanks.
0
0
0