Initial Support For The Rust Language Lands In Linux-Next

[ferry]

In other words, the only mainstream languages that you accept as existing are C, C++, C#, Fortran, Scheme, and whatever other languages either found it politically expedient to undergo standardization (C# and .NET), grew a standard after they had a forest of incompatible implementations to bring to heel (C, C++, ECMAScript... which is a subset of what real websites depend on, etc.), or are 40+ years old.

Exactly. And the Linux kernel is not a website.

Java, Python, Ruby, Lua, and a whole bunch of other languages are in the same boat as Rust, with a reference implementation, one or more secondary implementations of varying completeness, and no official standard and standardization committee... and Rust does have a very rigorous public RFC process for evolving the language in a careful and documented way.

Remember how much fun we had with MS Java implementation? And how much Python code broke from 2.7 to 3.3?

Linux is not just a hobby project.

Rust already provides stronger forward compatibility guarantees for existing source code than C++, which does have a standard.

That's great. So the next step for Rust is to go for standardization. And then 3 years from now we might have a specification that is really stable. And that would be a good time to start writing kernel code (not just build scripts) in Rust.

[ferry]

Why is this a problem? It is not even mainlined. in a few months the required changes are in stable.




That statement is from 2014. And before the 1.0 release. Since then everything is fine.


YES, and the industry showed big commitment and founded the organization. Problem solved.


Ay, you have to try harder. We used to have better trolls on phoronix.

My intention is not to troll but to make people think about what makes a suitable (not necessarily good) language for a kernel. From Stack Overflow: "the kernel is typically compiled with gcc under -std=gnu89 the GNU dialect of ISO C90 (including some C99 features)".

Already selecting the gnu dialect (the logical choice at the time) causes trouble building with other compilers.

So IMHO a 20 -30 year old language will always win over a language for which you need to use the nightly build to even compile without build errors.

[Jonjolt]

Java, Python, Ruby, Lua, and a whole bunch of other languages are in the same boat as Rust, with a reference implementation, one or more secondary implementations of varying completeness, and no official standard and standardization committee... and Rust does have a very rigorous public RFC process for evolving the language in a careful and documented way..

Uh, what? A JVM can't be called a JVM unless it passes the TCK (go look at Microsoft and Google for legal battles), also JEPs (Java Enhancement Proposals) , JCP (Java Community Process), and JSR (Java Specification Request).

[brad0]

And so its finally time to re-write drivers in rust

That is not going to happen anytime soon.

[oleid]

My intention is not to troll but to make people think about what makes a suitable (not necessarily good) language for a kernel. From Stack Overflow: "the kernel is typically compiled with gcc under -std=gnu89 the GNU dialect of ISO C90 (including some C99 features)".

As last time you quoted something, you only quoted half of it, skipping relevant parts. Further down, same comment, they say:

End result: we may be able to move up to a newer stdc model eventually, but right now the newer models have some annoying deficiencies, so the traditional "gnu89" model ends up being the preferred one.

This was in response to a change in gcc release 5, which changed the default standard option from -std=gnu90 to -std=gnu11 (skipping -std=gnu99). The top-level Makefile in the linux git repo still refers to -std=gnu89 as of Fri 2020-09-18. (-std=gnu89 and -std-gnu90 are equivalent.)

So they stayed with the old standard as the newer ones got worse. Not because they are conservative. But that's no problem. In rust you can easily compile your code with a later or an earlier epoch version (as of today, there is 2015 and 2018).

So IMHO a 20 -30 year old language will always win over a language for which you need to use the nightly build to even compile without build errors.

Maybe it is entirely different? So maybe, since they are stuck with an old C version as it got worse with a later version, they are more likely to try something "more suitable" for the kernel?

By the way, do you even know *why* they need a nightly compiler? They need a nightly compiler since they need a feature which didn't get stabilized yet. *Probably* things about custom error handlers for allocations or something like that. It doesn't mean that those features are not stable as in "will crash all the time", it just means the API of that features might change. And it is okay for the kernel to depend on the nighly compiler for now, since they are probably contributing to the API design by testing it out.

[bearoso]

You will see it many times for sure, some things kernel needs to do like accessing hardware registers is unsafe by nature and requires unsafe code. As an example you can browse Redox code (an operating system entirely written in rust) and you will find hundreds of occurrences of unsafe keyword.

https://gitlab.redox-os.org/redox-os/redox

But if you calculate the percentage of code in unsafe blocks with respect to the entire codebase, the number will be very small. And if a memory error happens, you know you have to look only inside the unsafe blocks. That's a huge win!

That’s extremely optimistic. Most of the kernel deals with memory directly. It would be pointless to rewrite that in Rust code when half of it is marked unsafe, and you would prone to creating new memory errors in those sections.

There’s also the problem of LLVM. The kernel will never require LLVM, so any Rust parts must be optional.

[CommunityMember]

There’s also the problem of LLVM. The kernel will never require LLVM, so any Rust parts must be optional.

GCC will likely step up (and there is work is in progress for a rust frontend for GCC), or it will be left behind in favor of LLVM first. Same for the various kernel LTO and CFI features currently only supported when using LLVM (CLANG).

[chromer]

This is great but will it lead to huge size increase in kernel ?

[ssokolow]

Remember how much fun we had with MS Java implementation? And how much Python code broke from 2.7 to 3.3?

Linux is not just a hobby project.

First, a specification can't magically prevent non-compliant implementations. I may be wrong but, from what I remember, Microsoft Visual J++ got in trouble because it was an attempt to Embrace, Extend, Extinguish and Sun didn't take too kindly to Microsoft throwing their promotional weight behind a product specifically designed to get developers used to relying on proprietary extensions to Java that the reference implementation would never gain.

(Remember, that was the peak of Java's "write once, run anywhere" promotional push.)

Second, no spec in the world would have stopped the Python 2.7 to 3.3 break, because they'd just have redefined an existing Python spec as "the Python 2.x spec" and slapped whatever label was necessary onto Python 3.x to go with their plans for an API break, leaving third-party implementations to pick up the support burden for a standard they no longer wanted to support.

Third, Rust's stability promise and editions system were specifically designed with the intent to avoid something like that. (Rust took a lot of lessons from Python, including "a batteries-included standard library is where packages go to die and that's why Python 2.x has urllib and urllib2 in the standard library and everyone is pushed to use Requests, which depends on a urllib3 that refuses to become part of the standard library".)

With the exception of code that depended on a compiler bug to successfully build, you can still depend on and compile Rust 2015 code that hasn't been updated since it built on stable-channel Rust v1.0 in a project you start today, using the 2018 edition of Rust (or the new edition that's probably going to come out this year) and Rust 1.50.

That's great. So the next step for Rust is to go for standardization. And then 3 years from now we might have a specification that is really stable. And that would be a good time to start writing kernel code (not just build scripts) in Rust.

It's premature. Rust stopped making breaking changes at v1.0 on May 15th of 2015, making it less than a week over 6 years old today. It took over a decade for C to be standardized and likewise for C++.

C# was standardized two or three years into its lifespan because, again, political reasons. Having been kicked off the idea of EEE-ing Java, Microsoft wanted C# to steal Java's market share as quickly and effectively as possible... same way they greased palms and packed committees to get OOXML standardized to compete with OpenDocument, despite being such a blind XML-ification of MS Office binary formats that it preserves things like how early versions of Excel had buggy date code that manifests in how dates are represented in the files... when transitions from XLS to XLSX would be the perfect time to break from that legacy baggage.

Uh, what? A JVM can't be called a JVM unless it passes the TCK (go look at Microsoft and Google for legal battles), also JEPs (Java Enhancement Proposals) , JCP (Java Community Process), and JSR (Java Specification Request).

Yes but, last I checked, that was all Sun/Oracle (ie. not independent standards body) stuff equivalent to things Rust is already doing.

If Rust's existing procedures, test suite, and archive of RFCs don't qualify, then Java's don't either.

[reba]

This is great but will it lead to huge size increase in kernel ?

Not necessarily: https://lifthrasiir.github.io/rustlo...ble-large.html

To be honest I'm quite impressed by the versality and tool-support of Rust: https://os.phil-opp.com/minimal-rust-kernel/