Committing to Rust for kernel code

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