Skip to main content


From Jason Gunthorpe, maintainer of 5 Linux kernel subsystems:

IMHO the current situation of Rust does not look like success. It is basically unusable except for unmerged toy projects and it is still not obvious when that will change.


Today I learned that 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 an oops bug in production systems not caused by shared C code (unlike basically every other Linux GPU driver), is "an unmerged toy project".

(He works for Nvidia, I guarantee he's heard of it, considering we beat nouveau and NVK to GL 4.6 conformance.)

I guess this is what Linux kernel maintainers think of us Rust developers, that we only write "toy projects"...

This entry was edited (10 months ago)
in reply to Asahi Lina (朝日リナ) // nullptr::live

WTAF. The more and more I learn about kernel devs, the more I equate them to the vocal minority of the larger Linux community: toxic, entitled, gatekeepery, smarmy assholes.
in reply to Asahi Lina (朝日リナ) // nullptr::live

yeah.. we really need to focus more on getting stuff merged and I'd love for nova and asahi to work together on the bindings/abstractions so we can finally get things going here. And there are people more involved and knowledgeable with drm/kms working on nova, so I'm pretty confident that we can make this work.

And if it means we use a new drm_scheduler written in rust so be it.

in reply to karolherbst 🐧 🦀

@karolherbst would a DRM scheduler in Rust provide APIs also usable by C drivers in replacement of the bad C one ?
in reply to Sobex

@Sobex @karolherbst Probably not easily if written in idiomatic Rust with stuff like generics. I certainly don't plan to spend time thinking about that right now. It'd just be part of the driver, and if Nova wants to share it we'll move it to common Rust code.

Though you can always make wrappers work some way, so perhaps we could task the C people with writing C abstractions to the Rust scheduler if they really want to use it. Let them suffer the cross-language adaptation pain for once...

in reply to Sobex

@Sobex in theory yes. With rust you can specify the calling convention and every rust function can be compiled with the C one for compatibility.

And then you have "cbindgen" as a project to generate a C header file you simply include and link against.

The really nice think about rust is, that you don't need any kind of FFI code to call C or vice versa. Rust wrappers are really only about writing good abstractions, not about making it possible to use C code in rust or vice versa.

in reply to karolherbst 🐧 🦀

@karolherbst @Sobex You can write Rust that can be called from C, but you have to do that explicitly. The situation doing idiomatic Rust to C abstractions is actually worse than the other way around, because while Rust can support concepts like C struct embedding etc. (just unsafely), there is absolutely no way for C to directly interact with concepts like Rust generics. You'd have to introduce more explicit layers of abstraction in some cases with extra allocations and things like that.

And maybe that's a good thing. If we end up having high quality native Rust code in the kernel and C ends up being a second class citizen if it wants to use it, maybe that'll help convince the C people to learn Rust. We're certainly not going to degrade Rust code to C standards and design just so C people can interact with it in a C way.

in reply to Asahi Lina (朝日リナ) // nullptr::live

@Sobex oh sure, you can't map everything, but if you e.g. have a C API, you can implement that in rust just fine. And then C code can just call into rust code, which might be a better approach here than using cbindgen.
in reply to Asahi Lina (朝日リナ) // nullptr::live

@karolherbst @Sobex can you start with gccrust with the same architectural coverage? I still have phantom pains from projects stopping working because someone pulled in a dependency that wouldn't compile on perfectly capable machines, and it's starting anew with Python's Rust frenzy
in reply to Asahi Lina (朝日リナ) // nullptr::live

As an Asahi Linux user, thank you for your work. It is very much appreciated. I'm regularly stunned by how good the Asahi Linux experience is on my little old M1 Mac. Thank you.
in reply to Botahamec

@botahamec I think that must be something with your client/instance? It's very clear on the Mastodon/Glitch web and on Tusky.
in reply to Jérôme Petazzoni

@jpetazzo @botahamec Sounds like it strips block quote formatting and also collapses it with the next element. You should probably file a bug ^^
in reply to Asahi Lina (朝日リナ) // nullptr::live

And distro rust maintainers like myself (opensuse, suse) have worked with the kernel rust folk to address all the backporting and version stability concerns. Seems a lot more like kernel devs acting like this when faced with the prospect of change:
in reply to Asahi Lina (朝日リナ) // nullptr::live

"First they ignore you. Then they ridicule you. And then they attack you and want to burn you. And then they build monuments to you." - Nicholas Klein

quoteinvestigator.com/2017/08/…

in reply to Asahi Lina (朝日リナ) // nullptr::live

An angle I haven't seen mentioned is: where will all the new blood for the Linux kernel come from? I speculate that the average age amongst the Rust fans is lower than that of the C die-hards. If the Ted and friends are driving away the Rust people then Linux will suffer long-term.
This entry was edited (10 months ago)
in reply to Asahi Lina (朝日リナ) // nullptr::live

@awoo I'm learning Rust because it is, in my view, the successor to C/C++ that isn't tied to a major corporation, has a good community ecosystem, and is syntactically efficient, with a lot of extras that the old compilers don't have
in reply to Asahi Lina (朝日リナ) // nullptr::live

That video really captures a sad moment.

“I’M NOT GOING TO LEARN [new thing]!”

“WATCH HOW I PASSIVE-AGGRESSIVELY SABOTAGE YOUR [different thing], YOU SECOND-CLASS CITIZEN.”

in reply to Asahi Lina (朝日リナ) // nullptr::live

some people do amazing stuff and can still be blinded by their bias and obsession with a favourite tool.
You do amazing stuff too and there are a lot of us with macs wishing to high five the skin of your palms.
in reply to Asahi Lina (朝日リナ) // nullptr::live

block all attempts at merging useful Rust code in the kernel -> claim that all Rust kernel projects are unmerged so the situation is a failure. Makes perfect sense.
in reply to Pierre Bourdon

lol he actually made that argument in his reply. I'm speechless.

> AGX is currently unmerged and serves a tiny and niche user base with no commercial relavance. That is an unmerged toy by my definition.

in reply to Pierre Bourdon

I love how he keeps on bringing up RHEL but Asahi *is* the reason why Fedora is turning on Rust in distro kernels now. I'm pretty sure that's doing more to push RHEL to do that eventually than anything else.

Also there are literally companies investing in Asahi these days, just not ones who care about RHEL. But I guess he thinks only RHEL matters and anything else is "a toy" even though one such company has roughly ~the same market cap as RH did before the IBM acquisition today.

This entry was edited (10 months ago)
in reply to Asahi Lina (朝日リナ) // nullptr::live

I have been bothered by people revising history before ("nobody expected this" while I loudly expected it), but this is a revising of the present. I wish you strength!
in reply to Asahi Lina (朝日リナ) // nullptr::live

Shitposting (but only a bit):

Oh, that explains the "merging Rust will risk my NVidia investment!1" thing we saw on reddit.

Matrix Multiplications should be incredibly simple to abstract, yet NVidia's AI hype reduces to "the unmatched software quality" (lol yes but $3T market cap can't lie) that nobody else can deliver.

Now you threaten that ecosystem by creating _toys_ that work better than any commercial driver.

Yes, with that I would be very concerned about any NVidia investments.

This entry was edited (10 months ago)
in reply to Asahi Lina (朝日リナ) // nullptr::live

Yeh; although tbf I think Jason is from the RDMA side of things, which would have been Mellanox which Nvidia bought a few years back; I don't know if they speak to the GPU lot.
in reply to Asahi Lina (朝日リナ) // nullptr::live

The work you do on AGX is fucking AMAZING, beyond impressive. And I say that as someone who is usually on the "worried by rust" team, since I am quite fond of the more obscure architectures , which will probably never be supported by rustc. There seems to be a problem in attitude in *some* of the commercial kernel contributors, who think the linux kernel only exists to serve their bottom line, everything else is "toy projects" and "toy architectures" to them.
in reply to Asahi Lina (朝日リナ) // nullptr::live

Extrapolating one developer's words into "this is what kernel maintainers think" is an obvious logical failure and is not the way to advance the Rust cause. The fact that several kernel maintainers spoke out against the "unmerged toy" description makes it clear that it is not a majority opinion. There are a lot of people in the kernel community who support this work.
in reply to Jonathan Corbet

@corbet The problem is that as people in the Rust for Linux project we get to write all the abstractions to make things work, and that means interacting with many/all subsystem maintainers and therefore just one or two hostile maintainers can successfully derail the whole effort.

I'm already making a mental list of people to attempt to design around and avoid interacting with, and sometimes it's not even possible.

in reply to Asahi Lina (朝日リナ) // nullptr::live

If you approach a large city with a plan to install a shiny new utility system, you will quickly find yourself dealing with a whole range of bureaucrats, some of whom will be more helpful than others. The kernel project resembles that large city in a number of ways. I don't say this is a good thing, but it is a thing.

I believe that the Rust for Linux project is succeeding. Yes, it is slow and painful, but the people pushing this work are doing the right things and making progress.

The city council (the maintainers summit) is meeting on September 17. Rust will be on the agenda, and there should be a couple of Rust for Linux developers there. That would be a good time to have a well-thought-out proposal for process changes that you would like to see.

in reply to Jonathan Corbet

@corbet The difference is that people planning shiny new utility systems are probably on someone's payroll and still being paid regardless of how long the bureaucracy drags on or not, so at least they are getting some benefit (money) out of the painful process.

That doesn't really work like that in FOSS, especially not with non-commercial projects like Linux on M1. What that bureaucracy culture does is heavily benefit and prioritize the people employed to work on Linux and paid to deal with the red tape, and hurts people who are not and are just doing it for fun or to push the community forward, or as a side project and not their main employment.

The endgame is that you end up with a bunch of bitter people employed at big companies who do the work for the money, and have no interest in helping onboard new blood or support those who aren't motivated by a big paycheck to fight the community.

Obviously this doesn't describe the entire kernel community and there are good people working at big companies and still fighting the good fight... but I think it does describe how things are shifting overall, and how we're ending up here.

in reply to Asahi Lina (朝日リナ) // nullptr::live

I was actually trying to convince our IT staff to support Asahi running on company MacBooks. I'll give it another shot soon. We're not a huge company by any means, but if you name a helpful / non trivial (CAD or USD) dollar amount, I'll see what I can do.
This entry was edited (10 months ago)
in reply to Asahi Lina (朝日リナ) // nullptr::live

please don’t equate what one random maintainer says to what “this is what all kernel maintainers think”. I’m a daily user of this work and have been extolling its virtues whenever I’ve chatted to people about it. Let’s not turn this into anymore of a rust vs the kernel slander fest than it already is.
in reply to Jens Axboe

@axboe Already replied to @corbet: vt.social/@lina/11305718199671…

The problem is that when the Rust project needs to interact with a wide range of subsystem maintainers to put together usable Rust abstractions, just one or two acting in bad faith (or even simply not up to the task) can successfully derail the whole thing. We need active support from those who do want to see Rust happen... but we're not getting enough.


@corbet The problem is that as people in the Rust for Linux project we get to write all the abstractions to make things work, and that means interacting with many/all subsystem maintainers and therefore just one or two hostile maintainers can successfully derail the whole effort.

I'm already making a mental list of people to attempt to design around and avoid interacting with, and sometimes it's not even possible.


in reply to Asahi Lina (朝日リナ) // nullptr::live

@corbet we’re in violent agreement on that, merely saying that claiming all kernel maintainers are awful is not a great way to lobby for support.
in reply to Asahi Lina (朝日リナ) // nullptr::live

I'm no programmer, but it should be that any open source code that benefits the user is good code, regardless of programming language used. (Bonus points if it's well optimized too, lol)
in reply to Stormy178

@stormy178 Playing the devil's advocate here:
Some people I know are afraid it will affect the complexity to compile Linux and also how much time it takes to compile it.
in reply to MadMike77

@MadMike77 @stormy178 The Rust kernel core stuff compiles in almost no time. My driver takes a bit longer but that's because there's a lot of macro magic and it's compiling almost 5 different copies of the whole driver (for different GPU/firmware combinations). It's still an insignificant part of the complete kernel compile time.
in reply to Asahi Lina (朝日リナ) // nullptr::live

here I am reviewing Rust patches for Zephyr thinking Linux already had all of the political stuff sorted out 😂

If it makes a difference, I 💯 support what has been done in Linux with Rust.

There will always be resistance to change. Hopefully the resistance is less aggressive in the future. It sometimes takes thick skin.

I still strongly believe that Rust will reduce many of the common pitfalls hit by C developers (old and new), and that our systems will be more reliable as a result.

in reply to Asahi Lina (朝日リナ) // nullptr::live

I am so sorry to hear this. Please don’t let this get to you.

We know what your code means to Asahi community.

Stay strong Lina :)