Re: [PATCH -next] rust: fwctl: replace `__pinned_init` with `raw_try_init`
"Gary Guo" <[email protected]>
| Newsgroups | org.kernel.vger.linux-next,org.kernel.vger.rust-for-linux |
|---|---|
| Message-ID | <[email protected]> |
On Tue Aug 18, 2026 at 2:20 PM BST, Jason Gunthorpe wrote:
> On Tue, Aug 18, 2026 at 02:11:57PM +0100, Gary Guo wrote:
>> On Tue Aug 18, 2026 at 1:55 PM BST, Jason Gunthorpe wrote:
>> > On Tue, Aug 18, 2026 at 12:53:50PM +0200, Miguel Ojeda wrote:
>> >> Commit
>> >>
>> >> ea7da3116015 ("rust: treewide: replace `__pinned_init` with `raw_[try_]init`")
>> >>
>> >> from the pin-init tree replaced the method before removing it, but commit
>> >>
>> >> e052daab94ee ("rust: introduce abstractions for fwctl")
>> >>
>> >> from the fwctl tree added a new use.
>> >>
>> >> Thus replace that one as well to fix this error in next-20260817:
> [E0599]: no method named `__pinned_init` found for associated type `impl pin_init::PinInit<T, error::Error>` in the current scope
>> >> --> rust/kernel/fwctl.rs:465:49
>> >> |
>> >> 465 | match T::open(device, reg_data).__pinned_init(uctx_ptr) {
>> >> | ^^^^^^^^^^^^^ method not found in `impl pin_init::PinInit<T, error::Error>`
>> >
>> > If you delete functions like this then you break everyone elses branches :|
>>
>> I'm not sure how this break everyone elses' branches? It only breaks linux-next
>> but that's why it exists in the first place, to catch tree
>> conflicts.
>
> linux-next is to catch missed things, you shouldn't use it to
> purposefully cause conflicts during the merge window..
That is an accusation that I find unacceptable. The API removal commit lands in
linux-next almost 10 days before you pick the Rust fwctl series. The conflict
between rust and fwctl tree doesn't exist in next-20260814, the last linux-next
tag before Miguel sent the PR to Linus. How come I am purposefully causing
conflicts?
> So for example introduce your new API and do some conversions, then
> remove the old API down the road after the merge window is a more
> expected work flow.
I'd happily keep the old API for an additional cycle before removing it, if I
knew that there'll be additional users. However I couldn't predict that new
users will be added late in the cycle after I sent my pull request.
Best,
Gary