Re: Rust kernel policy

[Simona Vetter]

Hi Miguel

Disregarding the specific discussion here, but this just felt like a good
place to thank you for your work to bring rust to linux. Your calm and
understanding approach to figure out what fits best in each case, from "go
away, don't bother me with rust" through "I like this, but I have no clue"
all the way to "uh so we have four drivers now in progress, this is
getting messy" has and continues to enormously help in making this all a
success.

Thank you!

Obviously not diminishing everyone else's work here, just that Miguel's
effort on the culture and people impact of r4l stands out to me.

Cheers, Sima

On Fri, Feb 21, 2025 at 12:44:31AM +0100, Miguel Ojeda wrote:
> On Thu, Feb 20, 2025 at 7:42 AM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
> >
> > The document claims no subsystem is forced to take Rust.  That's proven
> > to be wrong by Linus.  And while you might not have known that when
> > writing the document, you absolutely did when posting it to the list.
> >
> > That is a very dishonest way of communication.
> >
> > And while you might not have known that when
> > writing the document, you absolutely did when posting it to the list.
> 
> I did know -- Linus told both of us in the private thread. I am not
> sure what that has to do with anything.
> 
> As I told you in the previous reply, please read the next paragraph of
> the document:
> 
>     Now, in the Kernel Maintainers Summit 2022, we asked for flexibility
>     when the time comes that a major user of Rust in the kernel requires
>     key APIs for which the maintainer may not be able to maintain Rust
>     abstractions for it. This is the needed counterpart to the ability
>     of maintainers to decide whether they want to allow Rust or not.
> 
> The point is that maintainers decide how to handle Rust (and some have
> indeed rejected Rust), but that flexibility is needed if a maintainer
> that owns a core API does not want Rust, because otherwise it blocks
> everything, as is your case.
> 
> In summary: you were in that meeting, you own a core API, you do not
> want Rust, you are blocking everything. So flexibility is needed. Thus
> we asked you what can be done, how we can help, etc. You did not
> accept other maintainers, did not want to have the code anywhere in
> the tree, nor wanted to work on a compromise at all. You, in fact,
> said "I will do everything I can do to stop this.". So that is not
> providing flexibility, quite the opposite of it. So Linus eventually
> had to make a decision to provide that flexibility.
> 
> I am not sure how that contradicts the document -- the document is
> precisely talking about this situation.
> 
> By the way, I do not take lightly that you accuse me of dishonesty.
> 
> > Which given the binding creep means every single non-leaf subsystem
> > eventually.
> 
> If Rust keeps growing in the kernel, then obviously more and more
> non-leaf maintainers get affected.
> 
> But that just means more people is getting involved and more
> subsystems are accepting Rust for their use cases. So that would just
> mean it was, indeed, a good idea in the end.
> 
> > I'm not sure how that matters.  Of course your Rust testimonials are
> > going to like it, otherwise you would not have quoted it.  They
> 
> Not at all. As I say in the talk, I included every single quote I got,
> even up to the night before the keynote.
> 
> It is nevertheless very biased, because I asked people we interacted
> with, which were mostly positive or neutral. I acknowledged this bias
> in the talk too.
> 
> However, just so that others are aware, I did email others that are
> negative about it too, such as you. And you did not reply.
> 
> > Well, obviously you do.  But as in many other things I would usually
> > not count corporate pressure as a good thing.
> 
> Corporate pressure is not good. Corporate support is.
> 
> And we need that support to accomplish something like this.
> 
> Cheers,
> Miguel

-- 
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch