Committing to Rust for kernel code

Posted Nov 24, 2023 12:52 UTC (Fri) by Conan_Kudo (subscriber, #103240)
In reply to: Committing to Rust for kernel code by ojeda
Parent article: Committing to Rust for kernel code

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.

to post comments

Committing to Rust for kernel code

Posted Nov 25, 2023 16:58 UTC (Sat) by ojeda (subscriber, #143370) [Link] (4 responses)

> 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

Posted Nov 25, 2023 17:21 UTC (Sat) by Conan_Kudo (subscriber, #103240) [Link] (3 responses)

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

Posted Nov 27, 2023 15:48 UTC (Mon) by ojeda (subscriber, #143370) [Link] (2 responses)

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

Posted Nov 27, 2023 16:10 UTC (Mon) by Conan_Kudo (subscriber, #103240) [Link] (1 responses)

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

Posted Nov 27, 2023 16:26 UTC (Mon) by ojeda (subscriber, #143370) [Link]

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