Message-ID: <20250223180330.GC15078@pendragon.ideasonboard.com>
Date: Sun, 23 Feb 2025 20:03:30 +0200
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Danilo Krummrich <dakr@...nel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
	Christoph Hellwig <hch@...radead.org>,
	Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
	rust-for-linux <rust-for-linux@...r.kernel.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	David Airlie <airlied@...il.com>, linux-kernel@...r.kernel.org,
	ksummit@...ts.linux.dev
Subject: Re: Rust kernel policy

On Fri, Feb 21, 2025 at 01:16:22PM +0100, Danilo Krummrich wrote:
> On Thu, Feb 20, 2025 at 04:39:58PM -0800, Linus Torvalds wrote:
> > Honestly, what you have been doing is basically saying "as a DMA
> > maintainer I control what the DMA code is used for".
> > 
> > And that is not how *any* of this works.
> > 
> > What's next? Saying that particular drivers can't do DMA, because you
> > don't like that device, and as a DMA maintainer you control who can
> > use the DMA code?
> 
> [...]
> 
> > So let me be very clear: if you as a maintainer feel that you control
> > who or what can use your code, YOU ARE WRONG.
> 
> When I added you to the original thread [1], it was exactly to get some
> clarification on this specific point.
> 
> In my perception, a lot (if not all) of the subsequent discussions evolved
> around different aspects, while this specific one is not even limited to Rust in
> the kernel.
> 
> Hence, I'm happy to see this clarified from your side; it was still a remaining
> concern from my side, regardless of whether the PR in question will make it or
> not.
> 
> However, I also want to clarify that I think that maintainers *do* have a veto
> when it comes to how the API they maintain is used in the kernel. For instance,
> when an API is abused for things it has not been designed for, which may hurt
> the kernel as a whole.

I've been thinking this through over the weekend, and I see an elephant
in the room that makes me feel uncomfortable.

Three important statements have been made on the topic of rust for
Linux. I'm going to include some quotes below, alongside with how I
understand them. My understanding may be wrong, please let me know when
that's the case.

- No maintainer is forced to deal with rust code at the time being.

  This was mentioned multiple times in different forms, for instance by
  Miguel in [1] as

  "Some subsystems may decide they do not want to have Rust code for the
  time being, typically for bandwidth reasons. This is fine and
  expected."

  or by Linus in [2] as

  > You don't have to like Rust. You don't have to care about it. That's
  > been made clear pretty much from the very beginning, that nobody is
  > forced to suddenly have to learn a new language, and that people who
  > want to work purely on the C side can very much continue to do so.

- No maintainer can (ab)use their power by nacking rust abstractions for
  the API their maintains.

  This was made clear by Linus in [2]:

  > So let me be very clear: if you as a maintainer feel that you
  > control who or what can use your code, YOU ARE WRONG.

- Breaking compilation of rust code in a released kernel is not allowed.

  This statement is less clear in my opinion. It's made by Miguel in [1]:

  "The usual kernel policy applies. So, by default, changes should not
  be introduced if they are known to break the build, including Rust.

  However, exceptionally, for Rust, a subsystem may allow to temporarily
  break Rust code. The intention is to facilitate friendly adoption of
  Rust in a subsystem without introducing a burden to existing
  maintainers who may be working on urgent fixes for the C side. The
  breakage should nevertheless be fixed as soon as possible, ideally
  before the breakage reaches Linus."

  The "ideally" in the last sentence is a subtle but important detail.

  Then we had some patches that broke the -next rust build and were
  dropped from v6.14, as mentionned in [3]. Greg

  > > Regardless of holidays, you seem to be saying that Linus should
  > > have accepted Andrew's PR and left rust with build failures?
  >
  > I can't answer for Linus, sorry.  But a generic "hey, this broke our
  > working toolchain builds" is something that is much much much
  > different than "an api changed so I now have to turn off this driver
  > in my build" issue.

  I haven't found a clear statement from Linus on this topic.

Those three statements can't all be true together, we can at best have
two. I would like to understand which one we will drop first, and I
believe many other developers and maintainers are wondering the same.

[1] https://rust-for-linux.com/rust-kernel-policy
[2] https://lore.kernel.org/all/CAHk-=wgLbz1Bm8QhmJ4dJGSmTuV5w_R0Gwvg5kHrYr4Ko9dUHQ@mail.gmail.com/
[3] https://lore.kernel.org/all/2025013148-reversal-pessimism-1515@gregkh/

> But as mentioned previously, I do not think that this veto can be justified with
> personal preference, etc.
> 
> - Danilo
> 
> [1] https://lore.kernel.org/lkml/Z5qeoqRZKjiR1YAD@pollux/

-- 
Regards,

Laurent Pinchart

Powered by blists - more mailing lists