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: <cd9d7dd56e8191eb2d61dce1c3fd88ccffcff690.camel@mailbox.org>
Date: Mon, 05 Jan 2026 22:11:40 +0100
From: Maurice Hieronymus <mhi@...lbox.org>
To: Gary Guo <gary@...yguo.net>, Danilo Krummrich <dakr@...nel.org>, Benno
 Lossin <lossin@...nel.org>
Cc: 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, 2026-01-05 at 16:11 +0000, Gary Guo wrote:
> 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.
> 
Before I start implementing, I want to reach common ground.

In my opinion a derive macro which implements Display would be
perfectly fine, as long as the name suggests what it does. So for
example #[derive(DisplayEnumVariant)]. This would communicate the
intent clearly to the user.

Benno, would you be okay with that? If not, Gary and Danilo, are you
fine with the proposed trait implementation (e.g. the variant_name
function)?
> 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.
> 
Are there any common use-cases where one wants to change the case of
the enum variants? If not, I would not implement an argument and rather
name the macro accordingly, so the intent is clear.

Thanks,

Maurice
> Best,
> Gary