LWN: Comments on "Committing to Rust for kernel code"

Committing to Rust for kernel code

rincebrain — Sun, 10 Dec 2023 11:26:04 +0000

...except almost all of iomap is EXPORT_SYMBOL_GPL, so anyone working on things that aren't GPL can't play in that sandbox.

Committing to Rust for kernel code

atnot — Sat, 02 Dec 2023 09:36:27 +0000

Not to get too far from the point, but there's another aspect to it.

It's perfectly possible for most decent home cooks to make a michelin star grade meal at home with a bit of practice... once. That's a large part of the joy of being a home cook, really.

But the actual skill and difficulty in a restaurant is in being able to deliver that type of quality consistently at scale hundreds of times a day, every week, for years. Every week will have different weather, shifting suppliers, fresh ingredients: a new recipie. Adjusting to all that requires immense ability and intuition from a whole team.

Committing to Rust for kernel code

jschrod — Fri, 01 Dec 2023 23:17:25 +0000

Well, I'm a foodie. In my experience all chefs from Michelin stared restaurants are readily willing to share their receipts.

The problem at hand: there are very few people who can reproduce them at home. And those who can do so, usually create their own receipts - by building upon the ideas of those others.

Actually, hanging out with chefs is astonishing similar to hanging around with free software enthusiasts.

Committing to Rust for kernel code

nim-nim — Wed, 29 Nov 2023 12:30:30 +0000

> don't Apple refuse to have anything whatsoever to do with GPL3

Apple is not the whole world

In fact a *huge* number of companies (both on the producer and user side) have been using (AL)GPL for years and are starting to realise the “communist hell” FUD is just FUD. And they’re complaining Red Hat is not free enough.

The loudest free software promoters for years have not been @FSF but VC players that try to use dual licensing tricks and other open-source-enabled antifeatures to force their customers to do things they have no interest in.

Committing to Rust for kernel code

Wol — Tue, 28 Nov 2023 11:51:23 +0000

You could always search for libc5 - the last linux libc. glibc2 became "libc6".

I've got some old software I would like to try and get running again (Y2K era) that needs libc5.

Cheers,
Wol

Committing to Rust for kernel code

paulj — Tue, 28 Nov 2023 11:06:11 +0000

Self answer, best source seems to be the Linux "libc" man page: https://man7.org/linux/man-pages/man7/libc.7.html - linux libc was a GNU libc 1.x fork.

Committing to Rust for kernel code

paulj — Tue, 28 Nov 2023 10:26:58 +0000

Speaking of pre-libc.... there seems to be nearly 0 information available on the Internet - at least, easily found via the indexes of my favourite search engines of the early (pre GNU libc) Linux libc.

What was its origin and history again?

Committing to Rust for kernel code

smoogen — Mon, 27 Nov 2023 18:00:28 +0000

>> glibc, GMP, GNOME, KDE, git

> Linux didn't use glibc for a long time.

I am probably confused by what you meant here.. From a distribution point of view:

1. That 'long time' over the length of Linux operating systems is now very short. Most operating systems had switched to upstream glibc by 6-7 years out of the first distributions.. so out of 20 year lifetime, about 1/3 of the time?

2. The libraries shipped on many of the early distributions were either glibc derived OR were GPL2 based. I think there were a couple of BSD based ones but I don't remember who shipped them.

That said, the licensing of the new kernel code would be up to the writers of the code and would be limited to BSD or MIT to be GPLv2 compatible. [The Linux kernel has BSD and MIT code in it.]

The one thing I have seen with GPLv2 kernel code versus BSD code has been that short term effects BSD code can make money but it also tends to have a short 'shelf-life'. Updates to parts get stuck away inside various companies and you end up with multiple people solving the same problem over and over again. The kernel code tends to be seen and shared around a lot more.. and fixes come in from various places. BSD maintainers I have known usually grouse about how hard it is to get fixes for their stuff. They know in talking with programmer Y that XYZ company knows the bug, fixed the bug, and has code.. but because the code could also be used elsewhere, etc.. it would need so many legal checkmarks to get it out no one is going to do it. [The same does happen with GPLv2 code.. but it seems that there is more of a 'we can't use this elsewhere since its already GPLv2 so meh share it.']

However I know that is also just my experiences and world view clouding my view.

Committing to Rust for kernel code

ojeda — Mon, 27 Nov 2023 16:26:27 +0000

> Your approach with RfL is mostly fine,

As I told you both here and in Zulip, please explain what is your proposal for improvement. If you do not have one, please do not assume or imply that things could be done better.

The Rust versions we pick may not be the best for you (in fact, they are already the best ones we can pick for you), but that does not mean Rust for Linux is governed or developed in a bad way given the current constraints.

> it's just we're not at a place where I would be comfortable recommending it to be enabled in a mainline distro kernel.

Like I told you in Zulip, I am not sure why this is relevant. Whatever you recommend does not change our constraints.

I also already told you that we ourselves tell general purpose distributions that it is early to enable the upstream Rust support.

> The forked alloc crate issue has to be resolved first.

No, the reason is not alloc. The fact that you say so concerns me, since that is an implementation detail for users.

The actual reasons are, for instance, that there are no users in-tree, MODVERSIONS, etc.

Committing to Rust for kernel code

Conan_Kudo — Mon, 27 Nov 2023 16:10:48 +0000

We are doing that approach downstream because we need to. Obviously for upstream purposes, we'd do things differently. Our downstream patches are intended to enable us to build with the latest Rust compiler available in Fedora. Your approach with RfL is mostly fine, it's just we're not at a place where I would be comfortable recommending it to be enabled in a mainline distro kernel. The forked alloc crate issue has to be resolved first.

Committing to Rust for kernel code

ojeda — Mon, 27 Nov 2023 15:48:35 +0000

I am aware of all that, which is precisely why I wrote what I wrote.

I am still not understanding what you are trying to suggest. That we take "completely untested" patches that attempt to support multiple versions? That is not how things work.

And even if we decided to support multiple versions, that would still not solve your problems, since you would still be ahead.

Committing to Rust for kernel code

pizza — Mon, 27 Nov 2023 14:24:01 +0000

> Unfortunately, this probably works better in a corporate setting than in a FOSS setting (where nobody has a budget, a PM, OKRs, etc.).

Don't forget that in the F/OSS setting you're much more likely to be (very) decoupled from the end-users of a given bit of code. Sure, you remove something today, but your general userbase is using LTS-type distros it could easily be years before they notice.

I suppose the more generalized way to put it is that this "take ownership of X" only really applies if the code in question is under active development, as opposed to simply being ignored because "it works and there's no need to mess with it"

Committing to Rust for kernel code

NYKevin — Mon, 27 Nov 2023 14:14:27 +0000

> There's a common definition of Legacy Code as "Code that is too scary to change and too valuable to delete".

At my workplace, one of the more useful rules of thumb* is that code must be understood by somebody, or else it must be removed (eventually, with appropriate care and planning). If deleting module X causes module Y to break, then you go to the owners of Y and tell them "either you take on ownership of X, or else you stop using it." If there are multiple values of Y, then they can fight it out amongst themselves.

Unfortunately, this probably works better in a corporate setting than in a FOSS setting (where nobody has a budget, a PM, OKRs, etc.). But I think it could still be an instructive analogy. Ideally, you should not have large heaps of code that nobody can read and everybody is too scared to delete. The question is, how do you get there from here?

* This is not a formal "rule" in the sense that it's a policy everybody follows. It's an informal best practice that I have heard from various high-level engineers.

Committing to Rust for kernel code

motk — Mon, 27 Nov 2023 01:14:25 +0000

Could we not have this conversation every other week just for once?

Committing to Rust for kernel code

Wol — Sat, 25 Nov 2023 17:36:07 +0000

> > Where's the difference? If it's GPL, commercially minded people won't use it, and you don't get anything back.

> Wrong premise again? Since Safari and Android do in fact exist, it's rather easy to show that you are incorrect.

Yep, they exist. However, I can't speak for Safari/Apple because I have nothing to do with that ecosystem, but don't Apple refuse to have anything whatsoever to do with GPL3? And as for Android, doesn't Google have a ban on GPL user-space? Safari and Android look extremely like exceptions to me ...

> I will stop this here because there can be no agreement if we can't even acknowledge real facts.

To misquote PJ, when dealing with real life, facts are squishy. Heck, even with your two examples, the companies involved are openly hostile to the GPL - they don't have anything to do with it if they can help it .. (Unless, in Google's case, I suspect they're quite happy to dump abandoned projects as GPL ...)

Cheers,
Wol

Committing to Rust for kernel code

Conan_Kudo — Sat, 25 Nov 2023 17:21:19 +0000

The approach we're currently taking is to do the minimal effort to enable the Rust compiler version shipped in Fedora, which is nearly always ahead of what Rust-for-Linux is tracking. Keep in mind that we're shipping new versions of rustc shortly after upstream releases them. I don't particularly care about supporting multiple versions of Rust, but depending on what the change is, it may look like it might work for multiple Rust versions even if that's completely untested.

Committing to Rust for kernel code

ojeda — Sat, 25 Nov 2023 16:58:33 +0000

> Most of the problems are in the forked "alloc" crate that's in-tree, not in the Asahi DRM driver code.

Glad to hear that; then if you take the upgrades we do, most of your problems should go away.

> The website also says not to send patches for making the tree compatible with newer Rust compilers, so we don't. Instead, we have patches downstream in the Asahi tree to make adjustments to fix it for newer Rust versions. (...) you don't want fixes for newer Rust versions

The website asks not to send upgrades to newer versions because we are handling those on our side already. What we recommend is that users take the upgrades that we put upstream, and then you do not need to deal with alloc anymore.

> you don't want fixes for newer Rust versions (...) But I'm still not happy about the fact you do not accept patches for fixing the code to work on newer Rust versions.

Again, we support a single compiler version for the moment, and we are already upgrading to newer versions if there are no blockers. Thus there are no "fixes" needed (modulo mistakes in the upgrade, of course).

I suspect you may be talking about supporting multiple versions and wanting to add workarounds for that, but that is a different discussion/approach altogether, and I don't recall you suggesting that? In fact, in that GitHub issue, you said:

"I think that as long as you use unstable features, you should be tracking the latest Rust compiler at their lifecycle. Once you're not using unstable features anymore, then widening the range of compilers supported is a reasonable conversation to have."

Committing to Rust for kernel code

ojeda — Sat, 25 Nov 2023 15:44:13 +0000

The alloc topic has been in discussion since essentially the beginning of the project. The original plan discussed with upstream Rust (and others) is documented in-tree, please see the rust/alloc/README.md file. In short, the alloc fork is meant to be temporary and the discussions with upstream Rust are ongoing.

Committing to Rust for kernel code

pm215 — Sat, 25 Nov 2023 14:04:08 +0000

My impression is that QEMU's stance on Rust is roughly "might be interesting but unless a group of Rust experts turn up who want to do the massive amounts of work involved in demonstrating and then implementing a transition plan, it's probably not happening any time soon". Some parts that can be offloaded into separate processes that talk some defined protocol have been done in Rust, but they are all out of tree separate projects. Rust in the main QEMU binary is a much trickier thing.

Committing to Rust for kernel code

LtWorf — Sat, 25 Nov 2023 13:19:48 +0000

> Where's the difference? If it's GPL, commercially minded people won't use it, and you don't get anything back.

Wrong premise again? Since Safari and Android do in fact exist, it's rather easy to show that you are incorrect.

I will stop this here because there can be no agreement if we can't even acknowledge real facts.

Committing to Rust for kernel code

Wol — Sat, 25 Nov 2023 11:39:47 +0000

> > From the *givers* point of view, MIT and GPL are pretty much the same thing

> From wrong axioms, a wrong proof follows. Unsurprisingly.

Where's the difference? If it's GPL, commercially minded people won't use it, and you don't get anything back.

If it's MIT, commercially minded people don't contribute back. (According to you, at least ...)

The mindset that says "pay forward, pay back", will contribute regardless of licence.

As I say, what's the difference?

And if the GPL has no teeth (because, like in my case, it's simply an inappropriate licence), again what's the difference?

Cheers,
Wol

Committing to Rust for kernel code

marcan — Sat, 25 Nov 2023 08:02:48 +0000

Hey Miguel,

I just opened a thread on the Zulip to talk about this. Conan doesn't have too much visibility into the actual work going into our downstream branch Rust support, but I do. And indeed, the biggest problem is 100% upstream: it's the `alloc` crate. That's what is breaking with almost every compiler version bump, and I haven't seen any discussion or plans for how that will be resolved yet.

Upstreaming, the small handful of features used in the other crates, etc. are all things with solid plans going forward, and I look forward to the future for Rust for Linux. But as long as `alloc` is using 100+ unstable features directly upstream, all the work to eventually drop the dozen features used in the `kernel` crate is rather useless. Being able to unpin the Rust compiler version is very important for distros to start taking this seriously and reduce friction enabling Rust support, so I hope there is some plan to eventually solve this. Maybe there is and I just haven't found it? Would be happy to hear your thoughts :)

Committing to Rust for kernel code

LtWorf — Sat, 25 Nov 2023 07:32:25 +0000

GPL is not imposed. If you use it it was because you have decided to somehow obtain the software, and you have no obligation of doing so.

You can write your own, pay someone else to do it, just not use that particular software. If you are ok with windows having an EULA, I don't see what your problem is with a much less restrictive GPL license.

> From the *givers* point of view, MIT and GPL are pretty much the same thing

From wrong axioms, a wrong proof follows. Unsurprisingly.

From the author's point of view, GPL means a much greater chance of getting improvements and contributions. See webkit, it exists because apple had to release it because KHTML was LGPL. Otherwise apple would have just never released their modifications. I do this assumption because the rest of safari was never open sourced.

So the givers of LGPL KHTML got webkit (wich wasn't that nice, because it was not a direct replacement), but it's more than with MIT.

If you are scared of the legal threat of the GPL and feel constrained by the clause that you must pass on the same freedoms, your intentions were never good to begin with; and as an author of free software I'm completely ok with ill intentioned people never using my software and interacting with me via bugreports.

(Of course in reality the ill intentioned people open bugreports to inform me of how dumb/evil I am for not letting them use my work to take freedom away from others… So I wrote a code of conduct that forbids this behaviour and I can at least instantly ban them).

> (Yes, I know, only if you choose to share what others gave you, but the GPL applies coercion, MIT gives you choice)

And seeing how the former CEO of github was pushing for MIT license (https://www.youtube.com/watch?v=-bAAlPXB2-c), microsoft continuing on the same path, apple avoiding GPL3, google completely forbidding AGPL… it seems that humanity isn't enlightened enough yet to not need the coercion.

Committing to Rust for kernel code

tlamp — Fri, 24 Nov 2023 20:02:15 +0000

IME the hardest part is writing good and rust-idiomatic bindings, but once that hard work is done (yes, often by experts) working with them can be done by non-experts too.

ps. How's QEMU's stance on rust? Our backup driver [0][1] would surely look a bit nicer with more native support.

[0]: https://git.proxmox.com/?p=proxmox-backup-qemu.git;a=summary
[1]: https://git.proxmox.com/?p=pve-qemu.git;a=blob;f=debian/p...

Committing to Rust for kernel code

Wol — Fri, 24 Nov 2023 19:55:35 +0000

> Arguably also getting on a drakkar and raiding england is a way to make a living that current pesky laws have forbidden. Perhaps not all ways of making a living are equally good?

The difference is do you want to live in a commune, or a communist state. Both are supposedly "share and share alike". But a commune is from choice, communism is imposed.

From the *givers* point of view, MIT and GPL are pretty much the same thing - you chose to give it away. From the recipient's pov, MIT gives you that same choice, that same freedom. GPL forces you to give your stuff away, under threat of lawsuit ...

(Yes, I know, only if you choose to share what others gave you, but the GPL applies coercion, MIT gives you choice)

Cheers,
Wol

Committing to Rust for kernel code

beagnach — Fri, 24 Nov 2023 15:27:34 +0000

Yes, but we all know that's not relevant to the discussion at hand because no one could seriously advocate for it to replace C for general kernel development.

Committing to Rust for kernel code

orangetuba — Fri, 24 Nov 2023 14:27:14 +0000

Do you also think that restaurants should publish all their recipes, and that not doing so is equivalent to limiting other people's freedom?

Committing to Rust for kernel code

Conan_Kudo — Fri, 24 Nov 2023 12:52:55 +0000

Most of the problems are in the forked "alloc" crate that's in-tree, not in the Asahi DRM driver code. The website also says not to send patches for making the tree compatible with newer Rust compilers, so we don't. Instead, we have patches downstream in the Asahi tree to make adjustments to fix it for newer Rust versions.

My complaints around my patch load are centered around two things: you don't want fixes for newer Rust versions *and* DRM (despite being mostly enthusiastic about Rust) has been stalling on the reviews. The latter issue is apparently resolving itself now, so we may see progress on that front. But I'm still not happy about the fact you do not accept patches for fixing the code to work on newer Rust versions.

Committing to Rust for kernel code

ballombe — Fri, 24 Nov 2023 12:32:44 +0000

if the kernel is required to work with both compilers, this will slowdown the rise of the 'minimal supported version' of rustc

There have been situation where you could not build a newer release of firefox because the rust compiler provided the distro was too old, and that upgrading rust was a major update.
This is something I am sure a lot of kernel users are concerned about.

Committing to Rust for kernel code

khim — Fri, 24 Nov 2023 11:38:04 +0000

> though nobody cares because it's broken somewhere related to a nightly/unstable feature

Also, please, note that this is gross exaggeration: while unstable features can be deliberately changed at any time (that's why they are marked “unstable”, after all) if something is broken by accident then rustc developers take bug-reports seriously.

Have you tried to create in issue against rustc? Yes, they may ask you to change your code, if you use unstable feature, but “nobody cares” is the exact opposite from what I observed.

Firefox and many other large companies use Rust unstable features — do you think it would have worked for them if nightly features were in the state of being perpetually broken?

And if you have filed the issue then looking on it would be better than talking about abstract issues in vacuum.

Committing to Rust for kernel code

Wol — Fri, 24 Nov 2023 09:17:46 +0000

> glibc, GMP, GNOME, KDE, git

Linux didn't use glibc for a long time.

Dunno about GMP, but Gnome and KDE relied on X which was BSD. Didn't we have Lesstif? And git was written by Linus, who is famously a pragmatist and doesn't really agree with the GPL. He used it because it was available, and did what he wanted.

So I think pretty much EVERY one of your examples could easily exist in a world where the BSD lawsuit didn't happen, and Linux was never born.

What other differences such a world would involve I don't know.

Oh - and again as I keep repeating, in many cases there is NO REAL DIFFERENCE between GPL and MIT/BSD. What's the difference if you apply them to interpreted scripts? Zilch. What's the difference if you apply them to a p-code system like Pick/MV that has no concept of linking? Zilch.

That's why my licence of choice would probably be LGPL / MPL. The GPL brings nothing at all to the table, and the other two "actively encourage" share-and-share-alike. Plus, I work for an end-user (almost always have), so I don't feel the "make a living from software" pressure, despite being a 100% through and through developer.

Cheers,
Wol

Committing to Rust for kernel code

wtarreau — Fri, 24 Nov 2023 08:42:21 +0000

I'm speaking about implications of a fast-moving toolchain. When a toolchain moves fast the code can diverge quickly, to reach a point where backports are extremely complicated because sometimes they rely on a lot of new infrastructure. We've seen issues in the past where backporting fixes was a real mess. I'm thinking about the IRET bug for example, which required significant adaptations to the old code, backporting some infrastructure stuff while trying hard not to break anything. We could estimate ourselves lucky that the asm language did not evolve over all these years and that the infrastructure parts could be backported without other particular dependencies. But when you don't have all the underlying infrastructure available in older releases because it came with newer versions of the language, it's not the same game anymore. I was definitely not speaking about developers being lazy, just difficulties caused by dependencies on an updated version of a toolchain. That's not something we're used to with gcc, in the worst case it just requires less clean code.

Committing to Rust for kernel code

Cyberax — Fri, 24 Nov 2023 03:59:51 +0000

> free equivalents of which might or might not exist in a world without copyleft.

FreeBSD exists, LLVM exists, musl libc exists as well.

Also, it doesn't really change the fact that MIT is a more flexible license. By choosing it, developers prioritize the long-term well-being of the project, rather than a momentary gain (from people forced to open proprietary contributions).

Committing to Rust for kernel code

ojeda — Fri, 24 Nov 2023 02:33:51 +0000

> It fails to compile because something has broken in rustc in some way, or the unstable feature has changed and broken something, or both. It happens without fail.

The kernel only supports a single version of rustc for the time being (as the page mentioned above explains). Obviously, if you are using an unexpected compiler and also have out-of-tree code with extra unstable features, then you will need to handle the upgrade work yourself (which is why upstreaming would help).

One of the reasons why we started tracking the latest Rust release more closely is because it could help some very early users, including you. So I am not sure what you still expect us to do — I already told you back then that the kernel tracking the very latest Rust release would not solve all your problems (and, in fact, if you are dealing with a ton of out-of-tree code, then it may have been best for you that the kernel did not change versions that often and simply provide the right toolchain on your side).

> You still allow *new* unstable features to be used. That list will keep growing. And in fact, I know it will once the DRM stuff is incorporated into mainline RFL (whenever that happens). It's only a priority once you start saying "no" to adding more of them. That can't happen for a while yet since the various subsystems don't yet have Rust abstractions in mainline.

Please read the second page I mentioned earlier. You seem to believe that the features included in the initial minimal Rust merge were the only ones that we would need to use, forever. This is not the case, and we even have an issue (started in 2020) in our tracker listing the features we expect to need (linked from the other page too).

Moreover, it is also not the case that all features are treated equally (e.g. not all have the same timelines or the same degree of stability) nor that we add them just because we fancy them (the default answer is "no", in fact), which is what one could understand from your different comments in this article. Again, please refer to the page above.

Furthermore, whether some code is in mainline or not is irrelevant. You seem to believe that any maintainer in the kernel is able to start using any feature they like, which is not true. On top of that, for code outside abstractions, we are way stricter on the use of unstable features.

Finally, we are doing our best to work with the Rust project (and other entities) to try to get to the point where we can eventually declare a minimum version. So I really do not appreciate that you imply we are somehow careless about our usage of unstable features.

> I mean that you do not have a specification of how you want to handle Rust *in* Linux itself. This makes it really hard for people to figure out how to grade it and grok it when patches are being submitted to build new abstractions or kernel modules.

We are happy to help here, but it is unclear what you mean by "specification". What would you expect to see there? If you mean a contribution guide, we already have one among other documentation. Of course, we are still improving it and completing it, but others have already found it useful and successfully submitted patches.

> But I *can* expect the ones that *are* already doing Rust in other places to do more than nothing in the kernel. *My* patch load keeps growing because *nothing* has made it upstream in a year. It's extremely frustrating.

Why would you expect that? I am confused. Someone may like Rust, and even use it elsewhere (outside the kernel or in other areas of the kernel), but that does not mean they agree with using it within the kernel or in a particular area of it, or that they have the bandwidth to help you, or the expertise in a particular topic, or they may simply only work in the kernel as part of their job which may not include time for that, etc.

Anyway, I understand it can be frustrating, but it is what it is. Kernel maintainers, even those willing to help you, cannot simply merge code for the only reason of reducing your patch load. And, in case that is part of the confusion, kernel maintainers cannot randomly merge changes for areas they do not maintain. (To be clear, I don't know who you are referring to, i.e. I am not talking about anybody in particular.)

> I am shocked. I was also shocked when you said you reached out to all the major distributions, because I have not seen you reach out to Fedora *at all*.

Fedora already tracks the latest Rust compiler and Josh Stone has been involved in our issue tracker discussing the versioning policy (just like you were — see the first point).

And to be clear, I reached out to some that seemed to be able to provide a recent enough Rust release in their rolling user-facing releases. Something like Debian stable will obviously take longer, which is why when it came up in the summit I suggested providing the toolchain at kernel.org as another alternative that could perhaps help some people. Distributions could also provide a special package, like Ubuntu is doing — that would be great too and we would appreciate it.

> Insofar as Ubuntu shipping it, it's pretty easy when there's nothing to ship.

The point was that Ubuntu provides the toolchain required by the kernel, thus compiling the kernel should always work for them regardless of how much code or unstable features are in use in mainline.

> The Fedora Asahi Remix kernel has one of the most significant Rust-based kernel modules (the Asahi DRM driver), and it can't even build on Rust 1.73 because something is broken in rustc itself (though nobody cares because it's broken somewhere related to a nightly/unstable feature). My next rebase will be the next time I try with Rust 1.74, and I'm dreading it.

We cannot promise out-of-tree code compiles. The best route is to get the code upstreamed and use the compiler version expected by the kernel. The DRM maintainers are supportive of Rust, so that is definitely an advantage in your case.

I don't know why you say "nobody cares" or why you claim "something is broken in rustc itself", though. Please see the points above.

> I have recommended to upstream Fedora to *not* enable it because it's so risky to enable right now.

If by "risky" you mean "I get compile errors because I am carrying out-of-tree code with extra unstable features and use an unexpected compiler on top", sure. In any case, I would also not enable it until there is an actual in-tree module that their users actually need and the support is deemed production-ready. So for the time being I agree with your recommendation, even if for different reasons.

> Since we track upstream Rust on their compilers, Linux Rust code is busted all the time.

Linux Rust code is definitely not "busted". Again, if you are using out-of-tree code and an unexpected compiler on top of that, then that is something you will need to handle yourself.

Sincerely, it sounds to me like you are doing some things on your own, facing some difficulties for some time and then deciding that the best approach is to complain here. We already tried to help you in the past, and it seems you did not notice we started tracking the latest release. I think a better approach would be reaching out to us to see if we can help you further or at least to understand each other's context/constraints better.

Committing to Rust for kernel code

sfeam — Thu, 23 Nov 2023 20:26:05 +0000

Well, there was BPF...

Committing to Rust for kernel code

pbonzini — Thu, 23 Nov 2023 19:48:34 +0000

Rust is trivial to learn and insanely hard to master, let's not kid ourselves. Most maintainers in the kernel could not write (and could barely read) the code for some of the bindings. See for example the workqueue bindings, https://lwn.net/Articles/932271/ (might not be the last version, the point still stands).

The way it works is to trust that the people who contributed them, or someone else, will be around to help. Fortunately the Linux APIs are relatively stable, and changes are less frequent than people think, but I think it's reasonable at least for now to have even experienced C programmers ask for help, because introducing technical debt would be worse.

Committing to Rust for kernel code

pbonzini — Thu, 23 Nov 2023 19:41:59 +0000

> MIT is more advantageous for individual developers.

Only if they are not interested in using any of Linux, GCC, glibc, GMP, GNOME, KDE, git, etc., free equivalents of which might or might not exist in a world without copyleft.

Committing to Rust for kernel code

cozzyd — Thu, 23 Nov 2023 19:39:36 +0000

I don't think many people will agree that YAML is a more difficult language to learn than rust.

Committing to Rust for kernel code

mathstuf — Thu, 23 Nov 2023 18:29:11 +0000

> Users will be forced to perform major updates from 6.6 to 7.1 just because "ah that old driver you're using, no, we're not maintaining it anymore, it required and old version of Rust that was not convenient for us, why don't you upgrade your LTS instead?".

Who is offering LTS kernels but not supporting the drivers they ship with it? IIUC, the kernel community isn't going to say "hey, you want to maintain this driver but we don't want you to, so we're ripping it out" is it?

> But for other use cases where it takes time to validate a version and adapt to it, it's another story.

Again, why would maintenance on the stable branch of the driver not be a suitable solution here? Presumably with the attitude the developers have in your scenario, they're not backporting anything anyways and not worried about conflicts.

Committing to Rust for kernel code

Cyberax — Thu, 23 Nov 2023 18:16:05 +0000

> Every developer is using far more code than what they contributed, so globally, the GPL is still a win for them.

Why? It's vice-versa. MIT is more advantageous for individual developers.

> Yes, you can say it is the "prisoner dilemma" all over and again and use MIT license to get an edge, but the "prisoner dilemma" terminology calls it "being selfish".

I think you might be confusing the "selfish" vs "selfless" choices here. GPL is the "selfish" choice, while MIT is a "selfless" choice that results in a better outcome if everyone cooperates.