Live data from Hacker News

Rust in the kernel is no longer experimental

lwn.net

551–560 of 853 posts

Re: Rust in the kernel is no longer experimental

#551

I need to check the rust parts of the kernel, I presume there is significant amounts of unsafe. Is unsafe Rust a bit better nowadays? I remember a couple of years ago people complained that unsafe is really hard to write and very "un-ergonomic".

    unsafe {
        // this is normal Rust code, you can write as much of it as you like!
        // (and you can bend some crucial safety rules)
        // but try to limit and document what you put inside an unsafe block.
        // then wrap it in a safe interface so no one has to look at it again
    }

Re: Rust in the kernel is no longer experimental

#552

Earlier quoted context omitted.

I'd say no, access to a larger pool of programmers is an important ingredient in the decision of what you want to write something in. Netscape pre-dated Java which is why it was written in C/C++ and that is why we have rust in the first place. But today we do have Java which has all of the rust safety guarantees and then some, is insanely performant for network code and has a massive amount of mindshare and available…

> But today we do have Java which has all of the rust safety guarantees and then some, is insanely performant for network code and has a massive amount of mindshare and available programmers. I'm not entirely convinced that Java has much mindshare among system programmers. During my 15 years career in the field I haven't heard "Boy I wish we wrote this in Java" once.

I've seen plenty of networking code in Java, including very large scale video delivery platforms, near real time packet analysis and all kinds of stuff that I would have bet were not even possible in Java. If there is one thing that I'm really impressed by then it is how far Java has come performance wise, from absolutely dog slow to being an insignificant fraction away from low level languages. And I'm not a fan (to put it mildly) so you can take that as 'grudging respect'.

The 'factory factory' era of Java spoiled the language thoroughly for me.

Re: Rust in the kernel is no longer experimental

#553
post #306

Earlier quoted context omitted.

A container class that needs cooperation from the contained items, usually with special data fields. For example, a doubly linked list where the forward and back pointers are regular member variables of the contained items. Intrusive containers can avoid memory allocations (which can be a correctness issue in a kernel) and go well with C's lack of built-in container classes. They are somewhat common in C and very rar…

At least for a double linked list you can probably get pretty far in terms of performance in the non-intrusive case, if your compiler unboxes the contained item into your nodes? Or are there benefits left in intrusive data structures that this doesn't capture?

The main thing is that he object can be a member of various structures. It can be in big general queue and in priority queue for example. Once you find it and deal with it you can remove it from both without needing to search for it.

Same story for games where it can be in the list of all objects and in the list of objects that might be attacked. Once it's killed you can remove it from all lists without searching for it in every single one.

Re: Rust in the kernel is no longer experimental

#554

Earlier quoted context omitted.

I'd say no, access to a larger pool of programmers is an important ingredient in the decision of what you want to write something in. Netscape pre-dated Java which is why it was written in C/C++ and that is why we have rust in the first place. But today we do have Java which has all of the rust safety guarantees and then some, is insanely performant for network code and has a massive amount of mindshare and available…

All the mainstream browsers do their own low-level graphics rendering (e.g., of text and icons and such). Is Java performant enough to do that?

Absolutely. Again, not a fan of the language. But you can transcode 10's of video streams on a single machine into a whole pile of different output resolutions and saturate two NICs while you're at it. Java has been 'fast enough' for almost all purposes for the last 10 years at least if not longer.

The weak point will always be the startup time of the JVM which is why you won't see it be used for short lived processes. But for a long lived process like a browser I see no obstacles.

Re: Rust in the kernel is no longer experimental

#555

Earlier quoted context omitted.

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…

>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. >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. Irony.

No, just Rust's original stated goal.

Re: Rust in the kernel is no longer experimental

#556

Earlier quoted context omitted.

Some pretext: I'm a Rust skeptic and tired of Rust Evangelism Task Force and Rewrite in Rust movements. --- Yes. I remember that message. Also let's not forget what marcan said [0] [1]. In short, a developer didn't want their C codebase littered with Rust code, which I can understand, then the Rust team said that they can maintain that part, not complicating his life further (Kudos to them), and the developer lashing…

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…

>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 that there is a specification (the specification donated by/from Ferrous Systems, might have significant issues), or prioritizing the kernel higher than Rust.

On the flip side there have been many downright sycophants of only C in the Linux kernel and have done every possible action to throttle and sideline the Rust for Linux movement.

There have been multiple very public statements made by other maintainers that they actively reject Rust in the kernel rather than coming in with open hearts and minds.

Why are active maintainers rejecting parts of code that are under the remit of responsibility?

Re: Rust in the kernel is no longer experimental

#557

Earlier quoted context omitted.

Yeah, if you need a linked list (you probably don't) use that. If however you are one of the very small number of people who need fine-grained control over a tailored data-structure with internal cross-references or whatnot then you may find yourself in a world where Rust really does not believe that you know what you are doing and fights you every step of the way. If you actually do know what you are doing, then Zig…

The point with the linked list is that it is perfectly valid to use unsafe to design said ”tailored data structure with internal cross-reference or what not” library and then expose a safe interface. 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. That is how all standard library collecti…

>>That is how all standard library collections in Rust works

Yeah and that's what not going to work for high performance data structures because you need to embed hooks into the objects - not just put objects into a bigger collection object. Once you think in terms of a collection that contains things you have already lost that specific battle.

Another thing that doesn't work very well in Rust (from my understanding, I tried it very briefly) is using multiple memory allocators which is also needed in high performance code. Zig takes care to make it easy and explicit.

Re: Rust in the kernel is no longer experimental

#558

Earlier quoted context omitted.

A few distros already do that. Of the top of my head, both NixOS and Arch enable the QR code kernel panic screen, which is written in Rust. Granted, those are rather bleeding edge, but I know a few more traditional distros have that enabled (I _think_ fedora has it? But not sure).

> both NixOS and Arch enable the QR code kernel panic screen Interesting, I use both (NixOS on servers, Arch for desktop) and never seen that. Seems you're referring to this: https://rust-for-linux.com/drm-panic-qr-code-generator (which looks like this: https://github.com/kdj0c/panic_report/issues/1 ) Too bad NixOS and Arch is so stable I can't remember the last time any full system straight up panicked.

Arch never failed me. The only time I remember it panicked was when I naively stopped an upgrade in the middle which failed to generate initramfs but quickly fixed it by chroot'ing and running mkinitcpio. Back up in no time

Re: Rust in the kernel is no longer experimental

#559

Earlier quoted context omitted.

> both NixOS and Arch enable the QR code kernel panic screen Interesting, I use both (NixOS on servers, Arch for desktop) and never seen that. Seems you're referring to this: https://rust-for-linux.com/drm-panic-qr-code-generator (which looks like this: https://github.com/kdj0c/panic_report/issues/1 ) Too bad NixOS and Arch is so stable I can't remember the last time any full system straight up panicked.

Yep, that's what I'm referring to. For now there aren't many popular drivers that use Rust, but there are currently 3 in-development GPU drivers that use it, and I suspect that when those get merged that'll be the real point of no return: - Asahi Linux's driver for Apple GPUs - https://rust-for-linux.com/apple-agx-gpu-driver - The Nova GPU driver for NVIDIA GPUs - https://rust-for-linux.com/nova-gpu-driver - The Tyr…

I believe Google has developed a Rust implementation of the binder driver which was recently merged, and they are apparently planning to remove the original C implementation. Considering binder is essential for Android that would be a major step too.

Re: Rust in the kernel is no longer experimental

#560
post #356

So what is written in Rust so far therein?

> Linux's DRM Panic "Screen of Death" > "There is no particular reason to do it in rust, I just wanted to learn rust, and see if it can work in the kernel." https://www.phoronix.com/news/Linux-DRM-Panic-QR-Codes

We certainly don’t want the BSOD to crash. So that’s a reason.
Post reply on HN