Linux Developers May Discuss Allowing Rust Code Within The Kernel

[CommunityMember]

It is cool that Rust helps people write better code

I would suggest that people are not writing better code in Rust (although the language does provide some syntax to improve code), but the code they write is better protected against unanticipated processing. One can argue about the numbers, but memory safety is a real problem with real code (one recent estimate is 70% of security issues are related to memory safety), and Rust eliminates an entire class of real world of memory safety issues. Eliminating those 70% can only mean a more secure kernel, even if limited to a specific subset of the kernel

[RahulSundaram]

Well it has worked very well in practice(not perfect) considering is probably one of the most stable projects around while been this massive, also Linus don't work alone, he has a whole tree of maintainers that filter a lot of the crappy code too

The stability improved through systematic efforts like adding unit, fuzzers and so forth. Regressions weren't uncommon at all in prior releases including large amount of discussions about how Linus doesn't scale or can't possibly understand all the bits. A couple of references

https://lwn.net/2002/0131/a/patch-penguin.php3

https://www.zdnet.com/article/even-linus-torvalds-doesnt-completely-understand-the-linux-kernel/

There is any one person eyeing all of the code and catching bugs, even including subsystem maintainers. Instead systematic efforts are part of why there is a strong interest in moving to a language like Rust because it addresses more of the issues with language features

[bachchain]

What if we just wrote good C code instead?

Every C programmer for the last 42 years:

[jacob]

What if we just wrote good C code instead?

Congratulations, you just missed the point completely. It's not just about "writing good code". Much more importantly, it's about being able to PROVE that the code is good. Rust makes that easy, C makes it strictly impossible.

[jrch2k8]

That is the very definition of a gcc-ism. It is non-standard. And while for experimental purposes it might be useful under the appropriate "ACCEPT-NONSTANDARD" flag, it is ultimately broken. Get it into the standard, or abandon it. There is zero excuse to not standardize except it you intentionally want to be special in order to be special (in other words, you quite explicitly do not want to play well with others).

You realize must of that code is 30+ years old and that literally every compiler have custom extension outside the standard hence "Extensions" starting with the mother of all out of spec compilers Intel Compiler and Microsoft VC? damn, i think even Borland Turbo C had extensions all over the place even when it was the golden standard of compilers.

The only reason you realize GCC had those extension is because you can compile Linux yourself, if you get hold of the NT kernel 6.2(win10) from Microsoft and tried to compile it with Clang, you probably would have to rewrite half of the damn thing just to make it compile(not cleanly) because literally every kernel have specifics that only exist on its preferred compiler, this is/was also true for Solaris(non FOSS Sun Days), old BSD's, MacOS, BeOS(back in the day), Plan9, etc.

I can almost guarantee money that Apple Clang have custom extension for MacOS current kernels as well, simply because kernels are so low level and unique cases that is very tough to work only with the standards because the fact it is an standard doesn't make 100% usable for 100% of the use cases and put new things into those standard could take years(and you are seeing some of that work paying off now)

[jrch2k8]

The stability improved through systematic efforts like adding unit, fuzzers and so forth. Regressions weren't uncommon at all in prior releases including large amount of discussions about how Linus doesn't scale or can't possibly understand all the bits. A couple of references

https://lwn.net/2002/0131/a/patch-penguin.php3

https://www.zdnet.com/article/even-linus-torvalds-doesnt-completely-understand-the-linux-kernel/

There is any one person eyeing all of the code and catching bugs, even including subsystem maintainers. Instead systematic efforts are part of why there is a strong interest in moving to a language like Rust because it addresses more of the issues with language features

Again, faults and all no other project this size has survived that long with such high level of thrust(even in the ages of the first windows NT releases, Linux was highly respected by its security) and even today Linux even tho had faults weren't even near the level of Microsoft or Apple. Also those changes are very fairly recent.

So compared to your ideal world, sure it may not be perfect but in the real world has worked Extremely well(again nothing is perfect) for 30 years, so i take Linus and his eyes until someone can prove other method can be better with hard data not wishes.

And here comes my point, I get Rust is the new hot thing but i have lived through a lot of hot new things that were going to change the world(Trust me TM) and guess what C/C++ didn't even notice them and still going strong and like a lot of hot new things before it, Rust simply don't have enough strength or backing to even be compared in the same class as C/C++. I do agree Rust provide some interesting new concepts that could expanded and used in the future but right now is a lot of wishes, nice ideas and assumptions and Linus is not the kinda guy is going to be crazy about it.

And to drive it home, main consumer(that anyone give a damn of) of Rust is Mozilla atm and honestly WebRender(the Rust poster boy) is not faster than Chrome C++ equiv, is not that much more stable(at least in my experience Chromium crash a lot less than Firefox with WebRender) it doesn't use that much less memory, it doesn't provide new unique features, it has not proven to improve development speed in any form or shape since Firefox is still miles behind Chromium and WebRender itself isn't feature complete compared to Chromium equivalents and honestly the security argument is mostly theoretical at this point since Rust don't have enough mileage or is widespread enough to do any assertion.

Don't get me wrong i get and know all the cool things RUST propose but is damn way too soon to even try go into the kernel, i think the best solution would be take some years consolidating itself on user space, getting big projects, showing tangible improvements, gaining developer support(probably that syntax will have to change, for anyone that didn't learn to code whatching youtube JS videos, is horrible, borderline unmaintainable) then you can be a contender.

[jaypatelani]

I am wondering why not ada? It is more robust and readable than rust.

[elatllat]

Well, [python] already is (sort of) in a number of the tooling and profiling directories (but those are not part of the running kernel)..

numbers for Kernel 5.4.51

find ./* -type f | perl -pe 's/.*[\.\/]//g' | sort | uniq -c | sort -rn | grep -vP " \d "
27632 c
22534 h
4028 txt
2514 Makefile
2119 rst
1794 dts
1451 Kconfig
1316 S
1291 dtsi
443 sh
313 json
237 gitignore
188 yaml
122 Kbuild
105 py
86 tc
81 config
70 TODO
69 Build
63 cocci
57 svg
51 README
44 boot
43 pl
34 Platform
32 litmus
29 debug
20 tbl
19 conf
16 lds
14 fuc
14 cfg
13 dot
12 fuc3
11 ppm
11 asn1
10 xsl
10 exceptions
10 1

[wizard69]

There are god reasons to get away from C, however I don't see this proposal as well planned and thus should be discarded.

It would be far better to port / fork Linux to Rust and then develop / port, all the tools required to effectively deliver Rust code into the kernel. "hey lets use another language" sounds great but we are likely years off before they could have all the tooling place to do it properly.

[Marc Driftmeyer]

The only person who you have to convince is Linus and I doubt he's interested or we would have heard so by now.