Re: [PATCH -next] rust: fwctl: replace `__pinned_init` with `raw_try_init`

Miguel Ojeda <[email protected]>
Newsgroups org.kernel.vger.linux-next,org.kernel.vger.rust-for-linux
Message-ID <CANiq72nS2zDKShxyxcO2EyV6R_6F8x2Pzj_Fs0n86wXBBx6E3Q@mail.gmail.com>
On Tue, Aug 18, 2026 at 10:46 PM Jason Gunthorpe <[email protected]> wrote:
>
> It is fine, just give it some thought. Your PR has a list of
> conflicts, and I saw one other of these pin ones there as well.
>
> Imagine adoption making it 10x and it won't scale. If there are things
> to adjust in Rust or process or whatever now is probably a good time
> to work on it.
>
> You don't want to end up stuck later on where you can't do the
> refactorings you want to do because of unmanageable merge conflicts!

Semantic conflicts are fairly rare for us so far -- this cycle we
happened to have two reworks going on at the same time. Normal
conflicts have also been fine and not too onerous either.

Given the treewide nature of the Rust tree, I think it is bound to
happen from time to time, i.e. even in years from now. Part of the
idea of the tree was precisely to handle this sort of change. It is
also why sometimes I close the tree late.

Of course, I agree that if it multiplies wildly, then it doesn't
scale. But we have been able to handle those in different ways so far.

At the end of the day, it is about striking a good balance. For things
like this instance, where we have a couple one-liner conflicts, then
it can be simpler to just close the change than a staged approach that
we did other times, as long as Linus and Mark are OK with it (a year
or two ago I asked Linus about possibly doing this kind of rework in a
different manner, but we didn't need it so far).

In fact, the only "surprise" here was really the fwctl change that
arrived after the merge window had already opened. Otherwise, this
cycle would have been business as usual.

Cheers,
Miguel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.