Re: [PATCH v5 4/5] rust_binder: consolidate transaction failure prints

[Miguel Ojeda]

On Mon, Aug 3, 2026 at 9:30 AM Alice Ryhl <aliceryhl@xxxxxxxxxx> wrote:
>
> diff --git a/rust/kernel/error.rs b/rust/kernel/error.rs
> index a56ba6309594..380cd3f7276b 100644
> --- a/rust/kernel/error.rs
> +++ b/rust/kernel/error.rs
> @@ -135,7 +135,7 @@ pub fn from_errno(errno: crate::ffi::c_int) -> Error {
>      /// Creates an [`Error`] from a kernel error code.
>      ///
>      /// Returns [`None`] if `errno` is out-of-range.
> -    const fn try_from_errno(errno: crate::ffi::c_int) -> Option<Error> {
> +    pub const fn try_from_errno(errno: crate::ffi::c_int) -> Option<Error> {
>          if errno < -(bindings::MAX_ERRNO as i32) || errno >= 0 {
>              return None;
>          }

Generally speaking, one should know from the context whether an
integer is supposed to be an error or not, and thus it is rare to need
this function instead of the public one (this one is private, and the
two callers are here, not elsewhere in `kernel`).

So I wondered if Binder needs this -- I noticed the change when doing
my usual go-through-the-ML exercise and asked Alice about it, since it
seemed to me like Binder could perhaps avoid using the fallible
operation (and maybe even define an `enum` for `BinderError` instead
of a `struct` to be more precise about when a `source` is needed).

Alice told me that the `Option` in `BinderError` is just meant for the
zero case, i.e. the raw integer there should not be a random value.
Thus, since the `if` already covers the zero case, it does look like
this could use the infallible operation since we do know statically it
should be an error (modulo a bug).

So it sounds like the change can indeed be avoided, which should also
improve the code.

In any case, if we keep it, then the `error.rs` change should be
mentioned in the commit message.

By the way, I am still happy to take the first three patches unless
Binder is picking this up.

Thanks!

Cheers,
Miguel