Message-Id: <DAVO878E49AN.1L5TPHANBBHE6@nvidia.com>
Date: Wed, 25 Jun 2025 23:07:22 +0900
From: "Alexandre Courbot" <acourbot@...dia.com>
To: "Jesung Yang" <y.j3ms.n@...il.com>, "Miguel Ojeda" <ojeda@...nel.org>,
 "Alex Gaynor" <alex.gaynor@...il.com>, "Boqun Feng" <boqun.feng@...il.com>,
 "Gary Guo" <gary@...yguo.net>, Björn Roy Baron
 <bjorn3_gh@...tonmail.com>, "Benno Lossin" <lossin@...nel.org>, "Andreas
 Hindborg" <a.hindborg@...nel.org>, "Alice Ryhl" <aliceryhl@...gle.com>,
 "Trevor Gross" <tmgross@...ch.edu>, "Danilo Krummrich" <dakr@...nel.org>
Cc: <linux-kernel@...r.kernel.org>, <rust-for-linux@...r.kernel.org>,
 <nouveau@...ts.freedesktop.org>
Subject: Re: [PATCH 0/4] rust: add `FromPrimitive` support

On Tue Jun 24, 2025 at 12:14 AM JST, Jesung Yang wrote:
> This patch series introduces a new `FromPrimitive` trait along with its
> corresponding derive macro.
>
> A few enhancements were made to the custom `quote!` macro to write the
> derive macro. These include support for additional punctuation tokens
> and a fix for an unused variable warning when quoting simple forms.
> Detailed information about these enhancements is provided in the
> relevant patches.

Thanks for crafting this! I have been able to sucessfully use it to
provide the implementations needed for Nova's `register!()` macro.

>
> While cleaning up the implementations, I came across an alternative
> form of the `FromPrimitive` trait that might better suit the current
> use case. Since types that implement this trait may often rely on just
> one `from_*` method, the following design could be a simpler fit:
>
>     trait FromPrimitive: Sized {
>         type Primitive;
>
>         fn from_bool(b: bool) -> Option<Self>
>         where
>             <Self as FromPrimitive>::Primitive: From<bool>,
>         {
>             Self::from_primitive(b.into())
>         }
>
>         fn from_primitive(n: Self::Primitive) -> Option<Self>;
>     }

This alternative form looks like it could be more suitable for us
indeed.

The userspace `num::FromPrimitive` is a bit too exhaustive to my taste,
as it makes methods available to build from primitives that we don't
really want. For instance, if I have an enum type that should only be
built from a `u16` or larger (because it has variants with values bigger
than 256), then it will still have a `from_u8` method, which looks
terribly wrong to me as the very fact that you are trying to build from
a `u8` indicates that you have mistakenly truncated the value at some
point, and thus you will possibly obtain a different variant from the
one you would get if you hadn't!

So from this perspective, having an associated type to indicate the
valid primitive type like you suggest sounds like an excellent idea. I
probably also wouldn't mind if we only supported that specific type
either, as callers can make the required conversion themselves and doing
so actually forces them to be conscious of the types they are passing
and be warned of potential mismatches.

But I guess that if we do so we can just introduce a derive macro that
implements `TryFrom` for us, without needing to introduce a new trait. I
might be too focused on my own use-case and would like to hear other
usage perspectives for this work.

If you add an associated type, I guess this means the derive macro
should have a helper attribute to specify it?

Another important aspect discussed on Zulip is the counterpart to
`FromPrimitive`, `ToPrimitive`. Here I feel more strongly that we should
*not* follow that the userspace `num` crate does, i.e. having all
operations return an `Option` - that would result in a lot of unneeded
error-checking code in the kernel. No, here it is pretty clear that we
should only provide infallible methods for the types that can store all
the possible values. Which is basically... one or several `Into`
implementations?

So indeed I'd like to understand first whether we actually need a new
trait, or whether our needs can be met by derive macros that provide the
right `TryFrom` and `Into` implementations. For nova-core, I think the
latter would be ok, but maybe I am missing the larger picture.

Powered by blists - more mailing lists