[ky738]

This is one of the many reasons why the kernel should have been written in Rust.

[jlgaddis]

Linux, which first appeared in 1991, should have been written in a language that didn't exist until 19 years later?

When will your rewritten-in-Rust version of the kernel be released?

[kardos]

A wholesale rewrite is fantasy, but piecewise replacement might be plausible.

Is it technically possible to write a driver in Rust and add it to the kernel in a reasonable way? That is, without gobs of fragile shims, etc.

[kogepathic]

> Is it technically possible to write a driver in Rust and add it to the kernel in a reasonable way? That is, without gobs of fragile shims, etc.

I think this is highly unlikely. The Linux kernel lacks an internal ABI [0] which would make writing drivers in a different language and targeting them at multiple kernel releases essentially impossible.

Many, many people and organizations writing drivers have complained over the years about the lack of an internal ABI. [1] [2] I would go so far as to say it's why Linux on ARM is such a dumpster fire. SoC vendors provide an SDK based on a certain kernel, and OEMs forever ship this kernel (with occasional backports for really severe bugs) because porting the device-specific changes to a newer kernel is just too much effort.

[0] https://en.wikipedia.org/wiki/Linux_kernel_interfaces

[1] https://stackoverflow.com/questions/827862/why-i-need-to-re-...

[2] https://news.ycombinator.com/item?id=9220973

[pjmlp]

Google created their own Linux driver ABI with Project Treble.

Basically, it transforms Linux into a kind of microkernel, with drivers being implemented on their own processes, using shared memory APIs to talk with the kernel, based on an IDL (Interface Description Language).

https://source.android.com/devices/architecture/hidl/

[kasabali]

Why do you think ABI compatibility is needed for wiring drivers in Rust? ABI compatibility is only needed for binary modules. Source compatibility should be enough for source code form.

[Jach]

Yes, Mozilla is doing just that for Firefox, and there are lots of demo projects. (There's even a minimal kernel example I have bookmarked somewhere...) The problem is that once you accept that, you open the door for many other languages that are arguably better than C and can be introduced piecemeal just as well. Like Nim, but others too. Now you have to decide which one you want to use, evaluate their various merits, it's not just a "use this hip one that pops up on HN every week". It's easier to just keep everything in C and propose out-of-band ways of making things better. (e.g. I don't think there are any unit tests in vanilla Linux but it wouldn't surprise me if there's a bank of unit tests some other groups have written to occasionally run the latest vanilla against. People have found bugs with fuzzers. Etc.)

[pjmlp]

Probably never.

But we have other UNIXes, that moved away from a pure C model, Inferno, NeXTSTEP and its descendants.

Regarding Linux, the kernel might never move away from C, but Android, Android Things and ChromeOS have very little of it exposed to userspace.

And then there is Fuchsia and Redox.

[pornel]

Joking aside, is there any hope of Linux doing anything else than just continuing to use C forever and using verbal abuse of patch submitters as the only safety layer?

[marcosdumay]

There's hope we move from Linux some day, into something with access controls between parts of the OS.

But Linux will be in C forever.

[pjmlp]

Not at all, UNIX is married with C.

[staticassertion]

Not really, no.

[swiley]

I'm almost certain this is a joke, in case anyone gets confused.

[ky738]

:^)