Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust in the kernel is no longer experimental

lwn.net

Post reply on HN
Print view View original

741–750 of 853 posts

Re: Rust in the kernel is no longer experimental

#741

Post by josephg »

accelbred wrote: post #606
josephg wrote: post #444

Earlier quoted context omitted.

I totally hear you about C friendly APIs not making sense in rust. GTK struggles with this - I tried to make a native UI in rust a few months ago using gtk and it was horrible. > Also, a more Rust-friendly model would have incured higher memory costs. Can you give some details? This hasn’t been my experience. I find in general rust’s ownership model pushes me toward designs where all my structs are in a strict tree,…

The code is written in an embedded style, i.e. no dynamic memory allocation or thread creation/deletion after program initialization. It's also prioritizing reducing memory usage over performance since we are targeting memory constrained devices (and our performance target is 10 tps and we have like 100k tps). Thus we'd use trait objects over monomorphization. Dynamic collections are also off the table unless backed…

You said above:

> Also, a more Rust-friendly model would have incured higher memory costs.

I'm not sure how modelling everything in a rust borrow checker friendly way would change anything here? Everything you're talking about doing in C could be done more or less exactly the same in rust.

Arenas are slightly inconvenient in rust because the standard collection types bake in the assumption that they're working with the global system allocator. But there's plenty of high quality arena crates in rust which ship their own replacements for Vec / HashMap / etc.

It also sounds like you'd need to write or adapt your own JSON parser. But it sounds like you might be writing part of your own JSON / Yaml parser in C anyway.

Re: Rust in the kernel is no longer experimental

#742

Post by josephg »

viraptor wrote: post #500
weebull wrote: post #456

Earlier quoted context omitted.

So if you're writing a device driver in rust... - Hardware access is unsafe - Kernel interface is unsafe How much remains in the layer in-between that's actually safe?

All logic, all state management, all per-device state machines, all command parsing and translation, all data queues, etc. Look at the examples people posted in other comments.

Yep. Its kind of remarkable just how little unsafe code you often need in cases like this.

I ported a C skip list implementation to rust a few years ago. Skip lists are like linked lists, but where instead of a single "next" pointer, each node contains an array of them. As you can imagine, the C code is packed full of fiddly pointer manipulation.

The rust port certainly makes use of a fair bit of unsafe code. But the unsafe blocks still make up a surprisingly small minority of the code.

Porting this package was one of my first experiences working with rust, and it was a big "aha!" moment for me. Debugging the C implementation was a nightmare, because a lot of bugs caused obscure memory corruption problems. They're always a headache to track down. When I first ported the C code to rust, one of my tests segfaulted. At first I was confused - rust doesn't segfault! Then I realised it could only segfault from a bug in an unsafe block. There were only two unsafe functions it could be, and one obvious candidate. I had a read of the code, and spotted the error nearly immediately. The same bug would probably have taken me hours to fix in C because it could have been anywhere. But in rust I found and fixed the problem in a few minutes.

Re: Rust in the kernel is no longer experimental

#743

Post by sunshowers »

jacquesm wrote: post #505
iurbwdj wrote: post #441

Earlier quoted context omitted.

One perspective is that Rust appears to be forced into the Linux kernel through harassment and pressure. Instead of Rust being pulled, carefully, organically and friendly, and while taking good care of any significant objections. Objections like, getting the relevant features from unstable Rust into stable Rust, or getting a second compiler like gccrs (Linux kernel uses gcc for C) fully up and running, or ensuring th…

I think the main issue is that it never was about how rust programmers should write more rust. Just like a religion it is about what other people should do. That's why you see so many abandoned very ambitious rust projects to tackle x,y or z now written in C to do them all over again (and throw away many years of hardening and bug fixes). The idea is that the original authors can be somehow manipulated into taking th…

> Rust should have done exactly one thing and do that as good as possible: be a C replacement and do that while sticking as close as possible to the C syntax.

The goal of Rust is to build reliable systems software like the kind I've worked on for the last many years, not to be a better C, the original goal of which was to be portable assembler for the PDP-11.

> Now we have something that is a halfway house between C, C++, JavaScript (Node.js, actually), Java and possibly even Ruby with a syntax that makes perl look good and with a bunch of instability thrown in for good measure.

I think Rust's syntax and semantics are both the best by some margin across any industrial language, and they are certainly much better than any of the ones you listed. Also, you missed Haskell.

Re: Rust in the kernel is no longer experimental

#744

Post by josephg »

_fe wrote: post #408
josephg wrote: post #399

Earlier quoted context omitted.

If rust didn’t provide value to the Linux kernel, there’s no way it would have made out of the experimental phase. Rust isn’t an invading tribe. It’s just a tool.

> If rust didn’t provide value to the Linux kernel, there’s no way it would have made out of the experimental phase. That’s “appeal to authority” fallacy.

You're right that I'm appealing to authority, but that doesn't make my argument invalid.

The people who decided rust has value in the kernel are linux kernel developers. Ie, traditional C developers who see value in using rust in linux. Rust in linux has caused plenty of headaches. If rust didn't add commensurate value to make the trouble worth it, it wouldn't be getting adopted.

Re: Rust in the kernel is no longer experimental

#745

Post by astrange »

anthk wrote: post #380
astrange wrote: post #313

Earlier quoted context omitted.

BSD development mostly works through the classic approach of pretending that if you write C code and then stare at it really really hard it'll be correct. I'm not actually sure if they've gotten as far as having unit tests. (OpenBSD adds the additional step of adding a zillion security mitigations that were revealed to them in a dream and don't actually do anything.)

They don't do anything yet they segfault some C turd from 'The computational beauty of Nature's. You have no clue about any BSD and it looks. Every BSD has nothing to do which each other.

Not sure if this is speech to text.

Re: Rust in the kernel is no longer experimental

#746

Post by leftyspook »

zaphar wrote: post #480
pjmlp wrote: post #466

Earlier quoted context omitted.

You mean as in "having fun"? "Although we entertained occasional thoughts about implementing one of the major languages of the time like Fortran, PL/I, or Algol 68, such a project seemed hopelessly large for our resources: much simpler and smaller tools were called for. All these languages influenced our work, but it was more fun to do things on our own." -- https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chis…

for a project like unix at the time and even linux now I think "having fun" is absolutely one of their needs.

I think when Fish shell announced the Rust rewrite, they especially highlit that, in the form of "being more attractive to contributors" as one of the reasons.

Re: Rust in the kernel is no longer experimental

#747

Post by vbezhenar »

avhception wrote: post #151
vbezhenar wrote: post #92

Earlier quoted context omitted.

One could rewrite curl with Perl 30 years ago. Or with Java, Golang, Python, you name it. Yet it stays written with C even today.

Your comment comes across disingenuous to me. Writing it in, for example, Java would have limited it to situations where you have the JVM available, which is a minuscule subset of the situations that curl is used in today, especially if we're not talking "curl, the CLI tool" but libcurl. I have a feeling you know that already and mostly want to troll people. And Golang is only 16 years old according to Wikipedia, by…

Java might not be the most popular VM in Linux, but let's talk Perl or Python. It's installed by default almost everywhere, it's probably impossible to find a useful Linux installation without these runtimes. So writing curl with Python makes perfect sense, right? It's memory safe language, good for handling inherently unsafe Internet data. Its startup time is miniscule, compared to typical network response. Lots of advantages. Yet curl is still written with C.

I've never used libcurl and I don't know why is it useful, so let's focus on curl. Of course if you want C library, you gotta write it with C, that's kind of weird argument.

My point is, there were plenty of better options to replace C. Yet people chose to use C for their projects and continue to do so. Rust is not even good option for most projects, as it's too low level. It's a good option for Linux kernel, but for user space software? I'm not sure.

Re: Rust in the kernel is no longer experimental

#748

Post by eru »

pjmlp wrote: post #320
eru wrote: post #311

Earlier quoted context omitted.

Though to be fair, POSIX is increasingly outdated.

GNU/Linux isn't the only system out there, POSIX last update was in 2024 (when C requirement got upgraded to C17), and yes some parts of it are outdated in modern platforms, especially Apple, Google, Microsoft OSes and Cloud infrastructure. Still, who supports POSIX is expected to have a C compiler available if applying for the OpenGroup stamp.

> GNU/Linux isn't the only system out there, [...]

Yes? I'm especially keen on the project to make just 'Linux' without any Gnu components. Jokes aside, yes, other operating systems exist.

> [...] and yes some parts of it are outdated in modern platforms, especially Apple, Google, Microsoft OSes and Cloud infrastructure.

Well, also on modern hardware in general. POSIX's idea about storage abstractions don't gel well with modern hardware. Well, not just modern hardware: atime has been cast aside since time immemorial. But lots of the other ideas are also dropping by the wayside.

In practice, we get something like 'POSIX-y' or 'close-enough-to-POSIX', which doesn't get a stamp from OpenGroup. I think Linux largely falls in that boat.

But regardless of that distinction, a C compiler is very much part of the informal 'close-enough-to-POSIX' class.

It's a bit of a shame that Unix has retarded operating system research for so long. Fortunately, the proliferation of virtual machines and hypervisors have re-invigorated the field. Just pretend that your hypervisor is your nano-kernel and your VMs are your processes. No need to run a full on Linux kernel in your VM, you can just have enough code running for your webserver or database etc, no general kernel needed. See eg https://mirage.io/

Re: Rust in the kernel is no longer experimental

#749

Post by eru »

brokencode wrote: post #479
weebull wrote: post #464

Earlier quoted context omitted.

I personally feel the Zig is a much better fit to the kernel. It's C interoperability is far better than Rust's, it has a lower barrier to entry for existing C devs and it doesn't have the constraints the Rust does. All whilst still bringing a lot of the advantages. ...to the extent I could see it pushing Rust out of the kernel in the long run. Rust feels like a sledgehammer to me where the kernel is concerned. It's…

I’m not so sure. The big selling point for Rust is making memory management safe without significant overhead. Zig, for all its ergonomic benefits, doesn’t make memory management safe like Rust does. I kind of doubt the Linux maintainers would want to introduce a third language to the codebase. And it seems unlikely they’d go through all the effort of porting safer Rust code into less safe Zig code just for ergonomic…

> I kind of doubt the Linux maintainers would want to introduce a third language to the codebase.

That was where my argument was supposed to go. Especially a third language whose benefits over C are close enough to Rust's benefits over C.

I can picture an alternate universe where we'd have C and Zig in the kernel, then it would be really hard to argue for Rust inclusion.

(However, to be fair, the Linux kernel has more than C and Rust, depending on how you count, there are quite a few more languages used in various roles.)

Re: Rust in the kernel is no longer experimental

#750

Post by eru »

ViewTrick1002 wrote: post #343
eru wrote: post #307

Earlier quoted context omitted.

> If you’re having trouble designing a safe interface for your collection then that should be a signal that maybe what you are doing will result in UB when looked at the wrong way. Rust is great, but there are some things that are safe (and you could prove them safe in the abstract), but that you can't easily express in Rust's type system. More specifically, there are some some things and usage pattern of these thing…

If you can't create a safe interface and must have the function then create an unsafe function and clearly document the invariants and then rely on the user to uphold them? Take a look at the unsafe functions for the standard library Vec type to see examples of this: https://doc.rust-lang.org/std/vec/struct.Vec.html#method.fro...

> If you can't create a safe interface and must have the function then create an unsafe function and clearly document the invariants and then rely on the user to uphold them?

Yes, that's what you do in practice. But it's no different--in principle--from the approach C programmers have to use.

Post reply on HN