[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wie_Winz7CtRCM62S2b1pWKN2Jt2wdGHgFBv=aBU8qwqg@mail.gmail.com>
Date: Sun, 23 Feb 2025 10:31:49 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc: Danilo Krummrich <dakr@...nel.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 Sun, 23 Feb 2025 at 10:03, Laurent Pinchart
<laurent.pinchart@...asonboard.com> wrote:
>
> > 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.
This is literally why linux-next exists. It's where breakage is
supposed to be found.
And guys, you have to realize that there is no such thing as "works
every time". Just this merge window, we had a case where I didn't pull
some stuff because it broke 'bindgen', and the reason was simply that
not a lot of people seem to be running the rust builds on linux-next.
But realistically, my normal build testing has had rust enabled for
the last year or so, and that was literally the first time something
like this happened.
So be realistic: can rust cause toolchain problems? Sure.
But we have that issue - and we've had it *much*more* - with the
regular C side too. We have those kinds of issues pretty much every
single release, and it's usually "this doesn't build on some esoteric
architecture that people don't test any more".
For example, this merge window I did have that unusual "this doesn't
work for my rust build" situation, but that one was caught and fixed
before the merge window even closed. Guess what *wasn't* caught, and
then wasn't fixed until -rc3? A bog-standard build error on the
esoteric platform called "i386".
Yes, linux-next is supposed to catch interactions between different
development trees. And yes, various build bots test different
configurations. But nothing is ever perfect, and you really shouldn't
expect it to be.
At the same time, people harping on some rust issues seem to do so not
because rust is any worse, but because they have internalized our
*normal* issues so much that they don't even think about them. EVERY
SINGLE RELEASE Guenter Rockl sends out his test-results for -rc1, and
EVERY SINGLE RELEASE we have new failed tests and most of the time we
have several build errors too.
Guys and gals - this is *normal*. You should expect it. Breakage
happens. All the time. And that has nothing to do with Rust. It has to
do with the fact that we are doing software development.
Ask yourself: how many problems has rust caused you in the last year?
I'm claiming that the main problem has been people who have been
forthing at the mouth, not the actual rust support.
So next time you want to write an email to complain about rust
support: take a look in the mirror.
Is the problem actually the rust code causing you issue, or is the
problem between the keyboard and the chair, and you just want to vent?
Linus
Powered by blists - more mailing lists