Linux-for-Rust or Rust-for-Linux

Posted Aug 30, 2024 21:09 UTC (Fri) by asahilina (subscriber, #166071)
In reply to: Linux-for-Rust or Rust-for-Linux by jgg
Parent article: Rust-for-Linux developer Wedson Almeida Filho drops out

> It is basically unusable except for unmerged toy projects and it is still not obvious when that will change.

I guess my Apple AGX GPU driver, which is the kernel side to the world's first and only OpenGL and Vulkan certified conformant driver for Apple Silicon GPUs, and also the FOSS community's first fully reverse engineered driver to achieve OpenGL 4.6 conformance, and which is used by thousands of Asahi Linux users in production, and that literally has never had a reported oops bug in production systems not caused by shared C code (unlike basically every other Linux GPU driver), is "an unmerged toy project".

Since you work for Nvidia, I'm sure you've heard of Nova, the up-and-coming Nouveau replacement driver that is also written in Rust using my Rust DRM abstractions. Is that also going to be "an unmeged toy project"?

This kind of demeaning of our work is why us Rust developers are getting very, very tired of the kernel community.

Linux-for-Rust or Rust-for-Linux

Posted Aug 30, 2024 22:41 UTC (Fri) by jgg (subscriber, #55211) [Link] (13 responses)

You should be very proud of what AGX has accomplished, it is amazing software, and an incredible piece of work. In fact everyone I've talked to about it has shared that view.

However, that doesn't change today's facts - AGX is currently unmerged and serves a tiny and niche user base with no commercial relavance. That is an unmerged toy by my definition.

There is nothing wrong at all with working on toy software. Linux itself started out as a toy, this is not an attempt to be demeaning.

The point, as pbonzini elaborated on, is a lack of "killer use case" to motivate RH to seriously turn on kernel Rust in RHEL10. AGX will not alter RH's plans.

Nova is barely started, let's wait a few years to see what impact it has. I'm optimistic that a completed Nova would convince several distros to turn on kernel Rust support. I was actually thinking primarily about the Rust NVMe driver.

Unmerged toy

Posted Aug 30, 2024 22:48 UTC (Fri) by corbet (editor, #1) [Link] (3 responses)

Honestly, "unmerged toy" seems like an unnecessarily dismissive term for something like this. How about "out-of-tree useful driver" - a term that we could apply to things like fwctl as well, perhaps :)

The story of why it is unmerged is something I've never quite managed to dig into, but would like to.

Unmerged toy

Posted Aug 31, 2024 20:32 UTC (Sat) by jgg (subscriber, #55211) [Link] (2 responses)

That's for the feedback John. It is admittedly hard to know where colourful language stops being entertaining and people are offended. For instance down below someone was calling m68k/etc a "museum architecture" which is a phrase I've seen many times before. It seems like a popular and accurate term to describe it, yet I would also think that is dismissive to the consistent work Geert and others put in.

Unmerged toy

Posted Sep 2, 2024 7:34 UTC (Mon) by roc (subscriber, #30627) [Link] (1 responses)

Feel free to popularize a different term to describe such architectures. We do need a term for the situation where the effort of supporting an architecture (across the entire project, so including the costs of vetoing changes that would benefit other architectures) exceeds the practical benefits of being able to run the latest kernels on machines of that architecture.

Unmerged toy

Posted Sep 6, 2024 7:36 UTC (Fri) by da4089 (subscriber, #1195) [Link]

> Feel free to popularize a different term to describe such architectures.

"Heritage" is the usual respectful euphemism, I think?

Linux-for-Rust or Rust-for-Linux

Posted Aug 30, 2024 22:49 UTC (Fri) by Ashton (guest, #158330) [Link]

Boy, the existing contributor base of Linux is not covering itself in glory today.

“Toy project”? Can you please try and not be so petty and rude?

Linux-for-Rust or Rust-for-Linux

Posted Aug 30, 2024 23:56 UTC (Fri) by airlied (subscriber, #9104) [Link] (2 responses)

Throwing out toy without defining what you mean(even with a definition, it's still not a great word choice), is not exactly a great look here.

Like do we consider the open-gpu-kernel driver from NVIDIA a toy because it isn't upstream?

Asahi is not a driver on the enterprise radar, it won't make RHEL sit up and notice but in does that make it a toy.

I count asahi as a very successful fact finding mission, that in the end is very hard to upstream in a reasonable manner. It's why nova is approaching this from the other end, and building a driver upstream, where we fix the interactions with other subsystems in order as we go, building the ecosystem upstream rather than having it done in a private fork.

The main current focus is driver model and Greg at the moment, next after that will probbaly be getting pci, platform and drm device bindings into shape, KMS modesetting (which Asahi didn't have to tackle), and then the actual nova project.

I've already written a rust implementation that talks to NVIDIA's GSP firmwares and encapsulate the unstable ABI in a similiar form to the Asahi work, and the advantages of this over a C project to do the same are immense. Like night and day difference in how much code had to be written.

I think Linus has said at last year maintainers summit that he was supportive of this, and he thinks it will happen, I think if people start acting as active roadblocks to work, rather than sideline commentators who we can ignore, then I will ask Linus to step in and remove roadblocks, but so far we haven't faced actual problems that education and patience can't solve.

Linux-for-Rust or Rust-for-Linux

Posted Aug 31, 2024 9:21 UTC (Sat) by Wol (subscriber, #4433) [Link] (1 responses)

> The main current focus is driver model and Greg at the moment, next after that will probbaly be getting pci, platform and drm device bindings into shape, KMS modesetting (which Asahi didn't have to tackle), and th

Given that is at least one (Christoff Hellwig) big developer (you make it sound like two - Greg KH) is throwing a lot of effort into cleaning up the kernel, sounds like they need to be brought on-side if they aren't already.

I'm picking up a lot about Rust-kernel bindings, and how the end result is much cleaner for both the C and Rust sides. So even if the resulting Rust work isn't merged, actually the effort spent creating the Rust interface would be a great help to both of them.

So you now have clean Rust interfaces for anybody who is interested ... and any "I'm not learning Rust" developers who tamper with those interfaces will get shouted at "don't you dare create any (C) bugs that this would have automatically caught!"

Cheers,
Wol

Two implementations - another benefit

Posted Sep 6, 2024 11:46 UTC (Fri) by jjs (guest, #10315) [Link]

Seen it in other projects. You get something that works. Someone else builds a clean implementation - and you start seeing the cleanup in the design/specs as you make the two compatible. Which, in the long term, helps both teams.

Not familiar with Rust, but it sounds like the efforts are having good benefits even without Rust being fully integrated.

Linux-for-Rust or Rust-for-Linux

Posted Aug 31, 2024 3:30 UTC (Sat) by asahilina (subscriber, #166071) [Link] (4 responses)

> The point, as pbonzini elaborated on, is a lack of "killer use case" to motivate RH to seriously turn on kernel Rust in RHEL10. AGX will not alter RH's plans.

You are aware that the AGX driver is in fact the reason why Fedora is turning on Rust support in upstream kernels, right? I'm pretty sure that is doing more to push RHEL to eventually do the same than anything else, today.

https://gitlab.com/cki-project/kernel-ark/-/merge_request...

Neal is part of the Fedora Asahi SIG.

(Won't comment on your insistence on the "toy" designation since other replies have already done so.)

Linux-for-Rust or Rust-for-Linux

Posted Aug 31, 2024 7:38 UTC (Sat) by airlied (subscriber, #9104) [Link] (3 responses)

Red Hat will not turn on rust prior to nova if I had to guess, I'm not seeing any other motivator, I don't see any other motivator.

Don't confuse Fedora, CentOS or ARK with Red Hat here. RHEL is the boss level here, but I don't really care about that, I only care about getting things upstream lined up.

I think a lot of the complaints about rust will evolve away once there is an interesting in-tree consumer, toolchain versions will stabilise, better toolchain support for things upstream needs etc

Linux-for-Rust or Rust-for-Linux

Posted Aug 31, 2024 11:11 UTC (Sat) by Conan_Kudo (subscriber, #103240) [Link] (2 responses)

No. Rust is getting turned on because drm_panic is written in Rust. I started working on this for enablement because of AGX, but we need it turned on ASAP because drm_panic is approved for Fedora Linux 42.

Nova is on literally nobody's radar right now because it doesn't exist beyond scaffold. There is no code that does anything yet, to the best of my knowledge, and there will not be any for a long while.

Linux-for-Rust or Rust-for-Linux

Posted Aug 31, 2024 12:10 UTC (Sat) by airlied (subscriber, #9104) [Link] (1 responses)

DRM panic in Fedora is not a Red Hat commitment to rust in RHEL. I think directly said not to confuse Fedora and Red Hat here.

Linux-for-Rust or Rust-for-Linux

Posted Aug 31, 2024 12:31 UTC (Sat) by Conan_Kudo (subscriber, #103240) [Link]

Based on the conversations I've had with the RHEL kernel team so far, the main blocker for RHEL is the lack of modversions support for Rust, which is being worked on. I do think it'll get enabled before Nova is in a useful state, because there are other little drivers in-tree where there are C and Rust versions and the Rust versions are better than the C versions.