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

@lina 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.

@lina 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.

@lina 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.

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

@Sobex @lina 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.

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

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

@lina @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.

@lina 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:

@lina I think you need a line break. I was confused where the quote ends.

@botahamec I think that must be something with your client/instance? It's very clear on the Mastodon/Glitch web and on Tusky.

@lina this reminds me of the phrase "cute embedded nonsense hacks" as a summary of the entire embedded Linux world.

@lina 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.

@lina @botahamec similar issue with the mastodon default android app 🤔

@lina I took a quick glance at Redox and even ran the demo (impressive progress). However it's clear that Redox is a Linux alternative, much like *BSD, not a drop-in replacement, with full application compatibility. I don't see it unseating Linux in any near future.

I used Linux from the start and hacked on the 0.12 kernel. I contributed the 1st SCSI driver to 0.95 and fixed bugs in the FPU emulation. The reason Linux made so much progress so fast was because the roadmap was ...
1/2

@lina ... laid out by POSIX and the GNU applications. Basically, runs these apps and you have instant value. Only once Linux reached feature parity with, say, SunOS did it start to seriously extend the feature space.

Redox seems IMO a bit too eager to reinvent the whole world and that will make it a niche effort.

@lina 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.

@delroth 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.

@jpetazzo @botahamec Sounds like it strips block quote formatting and also collapses it with the next element. You should probably file a bug ^^

@lina @botahamec Good idea, I just did! Thank you (your concise and accurate wording of the issue was really helpful! 🙏)

@lina 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.

@lina gcc rust compatibility is a non-opianated constraint against taking Rust code to anything in any arch defconfig.

@delroth @lina honesty Linus should just take a more strict approach on this. Like “stop this shit, I’m the leader of this project and we WILL merge rust stuff. Accept this or fuck off.” or something, idk

@luana @delroth @lina Good luck with that. Last time he took a stand, it was against C++.

@mrkeen @luana @delroth @lina Well, no. The last time he took a stand, it was to say sched_ext *will* be merged. He deferred it one cycle, but it's landing in Linux 6.12.

https://frontpagelinux.com/news/linus-torvalds-merging-extensible-scheduler-sched_ext-in-linux-6-11/

@lina 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.

@lina 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.

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

@lina 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.

@axboe @lina
Highly-respected kernel developers need to shut others' toxic shit down quick.

The longer these random maintainers go saying stuff like that without consequences the worse the culture gets.

@virtuous_sloth @lina nobody sees everything that’s going on, and won’t start policing in discussions that they aren’t even cc’ed on. And if I’m not cc’ed pn an email, I certainly won’t see it, too many other emails. My point is that throwing gas on the fire in the them vs us discourse isn’t useful imho, and neither is assigning one mentality to all maintainers as that’s provably false.

@axboe @lina Fair. But toxic people count on that.

@virtuous_sloth @lina yeah maybe :-(

@axboe Already replied to @corbet: https://vt.social/@lina/113057181996719212

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.

@lina 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.

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

@corbet @lina it is also not just one developer. Wedson did himself a diservice by linking to the end of the talk. That part isnt as bad as what happened before. Two people derailing a presentation, objecting before even _hearing_. Not listening to the replies and the organizers not intervening

@corbet @lina The level of ignorance of the 'I don't want to insult a language by comparing it with Java but...' guy. Saw self and imagined problem!

@corbet @lina at the same time the reaction in /r/rust shows how pretty much everyone is an asshole. One just doesnt notice because they are on 'your side'

@lina 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)

@stormy178 @lina 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.

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

@lina @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.

@lina 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.”

@lina

Lina, do you think you will encourage kernel people to engage with you when you say things like:

"I guess this is what Linux kernel maintainers think of us Rust developers"

In a venue where the person you are referring to has no right of reply nor likely even knows the post exists?

And do you think an LWN thread with the opinion of one person constitutes all linux kernel maintainers?

And what if the head of your project had repeatedly made this kind of post in the past, to his thousands of followers, with the same lack of right of reply? Would you characterise that as toxic or unhelpful in any way?

Do you think engaging like this is healthy? Or likely to be constructive?

I say that as somebody who abhores what happened to Wedson, supports rust in linux, admires your work, finds that amdgpu crap stupid, and may one day be a maintainer myself.

I also say that as somebody who very explicitly tries to improve the kernel in practice.

What's frustrating here is I have met Jason in real life, and found him to be lovely and open-minded, and I really think while his choice of words here is... yeah not wonderful... it is likely to be something of a failure of communication and overly brusque rather than intended as demeaning.

To me the idea that shitting all over kernel people over and over again will result in positive change is frankly mind boggling.

@ljs @lina I have a friend who is one of the best developers that I know. He had an interaction with a kernel dev over 20 years ago that forever turned him off of having anything to do with kernel development. I doubt that he is following what's happening but I'm sure that his opinion would be that nothing has changed.

@jameshubbard @lina based on a single post by a single person in an LWN thread on a specific technical topic?

Or dickery at a conference?

Do you think this reflects the kernel at large, or are you just going to assume that because somebody grossly misrepresented it, in precisely the way I critique?

I am sorry that happened to your friend, but do you see the problem here?

And how do you propose we improve things? Lambast people more? Shit on kernel devs more when drama is in the air?

Sounds very healthy.

@jameshubbard @lina another factor here is that there's zero coverage of people being kind, thoughtful, helpful, patience, etc. in the kernel.

Only coverage of the negative.

So people get this entirely false impression that it's some mad max style hate dome. While there are dicks and dickery (what area of human affairs is bereft of that exactly? He who is without sin etc.), I can assure you, that is not how it is.

But when things like that happen, that's what gets put out there.

@ljs @lina it's not a single comment on a single LWN article though. It was one of many in that thread. It was listening to the discussion at the conference that was probably the straw that broke the camel's back for that dev.

Do I believe that it's representative of all of the kernel community? No, but it's enough that it's obvious the community is still driving people away.

I'm on mobile, so hard to fully respond now.

@jameshubbard @lina No you do seem to think it's representative, clearly.

Otherwise what you're saying is total nonsense.

I'd kindly ask you, and assume it's due to you being on mobile, to engage with the latter part of my post.

EDIT: I'm struggling to find objectionable other posts - unless you feel being critical of rust in any way is unacceptable? Which I'm afraid is a silly position. Or you take umbrage with 'museum pieces' which is not only a point I agree with but _helps rust get into the kernel_ :)

@lina 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.

@lina @corbet 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.