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: <DFGL2QTNH7FE.93EN71L7BXFM@kernel.org>
Date: Mon, 05 Jan 2026 11:29:04 +0100
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Benno Lossin" <lossin@...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 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.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/nova-core/gpu.rs#n25