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: <20260105161110.5d1ab548.gary@garyguo.net>
Date: Mon, 5 Jan 2026 16:11:10 +0000
From: Gary Guo <gary@...yguo.net>
To: "Danilo Krummrich" <dakr@...nel.org>
Cc: "Benno Lossin" <lossin@...nel.org>, "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>, <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, 05 Jan 2026 11:29:04 +0100
"Danilo Krummrich" <dakr@...nel.org> 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.
> 
> 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 think the proposal is reasonable.

Being able to print enum name is very common and this is why crates like
`strum` exist.

Perhaps if we want to make user having a thought about what names to
expose to users, we can have the case conversion argument be mandatory, so
they are forced to make a choice rather than blindly stuck
`#[derive(Display)]` onto their enum.

Best,
Gary