Re: [PATCH v2 1/1] rust: refactor to_result to return the original value

["Onur Özkan" <work@onurozkan.dev>]

On Tue, 9 Sep 2025 22:05:53 +0200
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:

> On Tue, Sep 9, 2025 at 7:43 PM Onur Özkan <work@onurozkan.dev> wrote:
> >
> > That change was incompatible with v1 (due to the different
> > signature of to_result), which fails to build with my patch. This
> > version (v2) fixes the issue introduced in v1.
> 
> In that case, please try to avoid mentioning "broken" or "fix" or
> similar, i.e. there is nothing broken in the tree itself (the commit
> message should mention what is done in the patch). If you want to give
> extra clarifications, then you can always add them outside the commit
> message, below the `---` line.
> 
> In addition, if the changes here are required to be done all at once,
> then please do not rebase on top of regulator -- this would need to go
> into the global Rust tree. Otherwise, any changes that does not need
> to go at the same time should go separately so that it is easier to
> land.
> 
> Finally, I am not sure I follow the `unwrap_or(0)` here. If one passes
> a negative enough `i64`, wouldn't that mean `Ok` starts to be
> returned? Currently all negatives that are not codes are supposed to
> be bugs.
> 

I think the best approach would be to return `EINVAL` from `to_result`,
what do yo think?

> Either way, I think this should probably go on top of
> https://lore.kernel.org/rust-for-linux/20250829192243.678079-3-ojeda@kernel.org/,
> since that adds documentation, and thus it would be nice to adjust
> that one to whatever the generic one should do now, especially if the
> semantics are changing.
> 
> Thanks!
> 
> Cheers,
> Miguel

I will do that in v3.

Thanks,
Onur