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

On Tue, Aug 18, 2026 at 4:23 PM Jason Gunthorpe <[email protected]> wrote:
>
> My impression is the rust team is still learning how best to apply
> rust to linux. So things land and get changed around with a healthy
> does of compile breaking changes. In a certain sense they are building
> a unique kernel specific dialect of rust as they go.
>
> It's fine, and this particular case is managable, but my main point is
> as rust increases in scope a more accommodating process is needed to
> maintain the general kernel work flow.

So we have done that usual dance in the past, i.e. waiting a cycle or
more to move users over time etc., but in this case it seemed like we
could fix essentially all at once.

In other words, we do our best to avoid annoying others too much
(especially Stephen in the past, and Mark and Linus), since Rust is
not too common yet.

In Gary's defense, he definitely knows how that works -- in fact, the
commit where he removed the method only did it for the Linux kernel
(he has other users of that library, where he didn't remove the method
just yet), i.e. he was definitely thinking about it! :)

In this case, we weren't expecting more to appear, so we went with it
-- I could have asked him to wait a cycle, so it is also on me, but it
seemed minor (easy diff and missing it is "only" a build error in
certain cases), and Linus has been OK with us having minor semantic
Rust conflicts from time to time. He even tries to fix the conflicts
in Rust himself, just like in C, though he asks us for the test merge
/ diffs, for good reason, of course.

It is also true that, with Rust, as Mark mentioned, certain bits can
be a bit more painful vs. C. One more example of that that we had to
deal in the past is moving items across files even if identifiers do
not change name, because Rust items have paths (modules, like C++
namespaces). But at least for those we can usually use what is called
a re-export to expose the same item in two places etc.

I hope that clarifies, and sorry for the trouble!

Cheers,
Miguel