linux-kernel - Re: [PATCH v2 1/2] rust: macros: Add derive Display for enums

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <DFGQH1FOS007.3IG8XIBOBWTZI@kernel.org>
Date: Mon, 05 Jan 2026 15:42:50 +0100
From: "Benno Lossin" <lossin@...nel.org>
To: "Danilo Krummrich" <dakr@...nel.org>
Cc: "Maurice Hieronymus" <mhi@...lbox.org>, <aliceryhl@...gle.com>,
 <acourbot@...dia.com>, <airlied@...il.com>, <simona@...ll.ch>,
 <nouveau@...ts.freedesktop.org>, <dri-devel@...ts.freedesktop.org>,
 <linux-kernel@...r.kernel.org>, <ojeda@...nel.org>, <boqun.feng@...il.com>,
 <gary@...yguo.net>, <bjorn3_gh@...tonmail.com>, <a.hindborg@...nel.org>,
 <tmgross@...ch.edu>, <rust-for-linux@...r.kernel.org>
Subject: Re: [PATCH v2 1/2] rust: macros: Add derive Display for enums

On Mon Jan 5, 2026 at 11:29 AM CET, Danilo Krummrich wrote:
> On Mon Jan 5, 2026 at 10:02 AM CET, Benno Lossin wrote:
>> On Sun Jan 4, 2026 at 9:07 PM CET, Maurice Hieronymus wrote:
>>> Add a derive macro that implements kernel::fmt::Display for enums.
>>> The macro outputs the exact variant name as written, preserving case.
>>>
>>> This supports all enum variant types: unit, tuple, and struct variants.
>>> For variants with data, only the variant name is displayed.
>>
>> I don't think we should be adding this. Display is designed for
>> user-facing output and so it should always be carefully designed and no
>> automation should exist for it.
>
> In general I agree, but simple stringification of an enum variant for a Display
> implementation is a very common use-case and it seems pretty unfortunate to have
> to fall back to either do the below (especially if there are a lot of enum
> variants) or having to go the declarative path of doing something as in [1].
>
> Especially in combination with things like FromPrimitive and ToPrimitive it gets
> us rid of the cases where we need such declarative macro mess.
>
> Eventually, drivers will most likely implement their own proc macro for this or
> repeat the declarative macro pattern over and over again.

When the definition already uses declarative macros, adding the Display
impl there is the correct way to do it IMO. If it is just a normal
definition, then a match is annoying when you have many variants.

> Maybe we should just pick a more specific name for such a derive macro than
> macros::Display.
>
> Maybe something along the lines of macros::EnumVariantDisplay? We could also
> have an optional argument indicating whether it should be converted to lower /
> upper case.

I'm still skeptical about having a derive macro for `Display`. What
about adding & deriving the following trait instead:

    pub trait EnumVariantName {
        fn variant_name(&self) -> &'static str;
    }

To print this, you of course need to call the function, but it is much
more self-descriptive than printing the `Chipset` directly.

Cheers,
Benno