Linux and Rust-Lang

Hello,
Is it true that Linux will be rewrite in the Rust-Lang?
How about "LKML: Linus Torvalds: Re: Linux kernel in-tree Rust support" ?

Thank you.

What the Linux developers are discussing is the possibility of allowing some modules to be written in Rust and included in the standard distribution.

A full rewrite in Rust isn't on the table at this time. Linux is a giant codebase that mostly works-- rewriting the entire thing in Rust would be a decade-long project that stalls all other development.

13 Likes

Given that it has taken 30 years to get Linux to where it is today I think the prospect of it being rewritten in Rust any time soon is very unlikely.

See "Is It Time to Rewrite the Operating System in Rust?" by Bryan Cantrill : Is It Time to Rewrite the Operating System in Rust? - YouTube

It is high praise indeed that Torvalds is even discussing the idea of allowing Rust into the kernel. I was somewhat surprised given the dependency on LLVM it drags in.

7 Likes

It's definitely interesting to see where it's going. Regarding Rust, quoting from: 'It's really hard to find maintainers...' Linus Torvalds ponders the future of Linux • The Register

He [Linus] said that for things "not very central to the kernel itself", like drivers, the kernel team is looking at "having interfaces to do those, for example, in Rust... I'm convinced it's going to happen. It might not be Rust. But it is going to happen that we will have different models for writing these kinds of things, and C won't be the only one."

That's just hype.

People have spent man-centuries on that C code and it'd be silly to throw it all away by rewriting in another language.

It looks like they are paving the way to let Rust be used in new drivers and such, although there'd need to be a lot of scrutiny to make sure the language/toolchain is up for the task... Code used by the kernel has much stricter correctness and performance standards than your average app.

1 Like

There are talks that they are going to allow drivers and kernel modules to be written in Rust. The question is if Rust going to be allowed into the Linux source code repo together with all other kernel code (mainly C) or just as standalone modules that is not distributed with the Linux source code? If I remember correctly C++ was not allowed to be added to the Linux source code tree.

1 Like

For me it would make more sense, that if one starts a serious new OS project today , to be started in Rust.

Doing some Linux parts, of course, should not be off the table.

It's probably better to start off my not attempting to build a "serious new OS".

Linux started out as little more than a play thing for nerds.

Window started out in MS-DOS, which was a based on QDOS, which was a quick hack to make a 16 bit look-alike of CP/M.

Unix stared out as a quick and dirty OS to use when Multics was abandoned.

Mac has it's roots in that Unix.

The all time famous attempt at a "serious new OS" was Multics. Which collapsed under it's own weight. See google.

So who knows what might happen. Perhaps Redox is the seed of a "serious new OS" in Rust: https://www.redox-os.org/ ?

6 Likes

The current discussion is about including Rust code in-tree. Most of the kernel community doesn't care about external modules at all, to the point that if it's not in-tree, it might as well not exist. Rust kernel modules have been possible for a while though, e.g. tsgates/rust.ko.

7 Likes

Sure, good things can start small, as your examples show. The seed must be quite good to grow large later.

Just looking at the initial page "Drivers run in Userspace", it already gets my attention as a potential good seed. Kernel/user space switches are already a killer for multi-Gbps communication. And the meltdown/spectre fix exposed even more the issue.

Ironic, since "quick and dirty OS" it quite literally what QDOS stands for :slight_smile:

The problem with that is that since the niche of "FOSS OS that I can use as daily driver" is, for all their flaws, already filled by Linux and the BSD family, there is no real impetus for most people to actually grow that seed. Otherwise, Redox OS would be usable as a daily driver by now.
Note that by "usable as a daily driver" I mean more than "the os should boot and not crash". I should also be able to use common FOSS tools eg Firefox and Wireshark without it requiring me to port the code, it should be capable of hardware-accelerated media playback (including support for things like Vulkan and GPGPU) and there should be some nonzero level of commercial support for popular non-foss tools.

3 Likes

Thus, kernel will use both of them? The C language is insecure.
What is the future of Rust-Lang?
If the Linux kernel use Rust-Lang for the future of its development then is it possible that other projects that using kernel rewrite in Rust-Lang? For example, Xen hypervisor.
Is Redox-OS an active project?

Yes, if Rust gets approved.

The C language is insecure.

Languages aren’t secure or insecure, software is. Software written in C can also be secure, it’s just harder to do.

What is the future of Rust-Lang?

In the short term, it will continue to be developed as it has been, and hopefully gain wider adoption. In the long term, nobody knows; it probably has enough traction at this point to stick around in one form or another.

If the Linux kernel use Rust-Lang for the future of its development then is it possible that other projects that using kernel rewrite in Rust-Lang? For example, Xen hypervisor.

Anything is possible, but these questions are better addressed to the developers of those projects. Only they know their intentions.

Is Redox-OS an active project?

The last commit was 2 days ago, so yes.

2 Likes

The think I would like to see, is a good integration between Rust and BPF. Preferably, automatic, with BPF programs been correct just because they compile, integrated into main code seamlessly through promises or any other async mechanism...

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.