From: Andreas Hindborg <a.hindborg@kernel.org>
To: "Gary Guo" <gary@garyguo.net>,
"Filipe Xavier" <felipeaggger@gmail.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>
Cc: daniel.almeida@collabora.com, rust-for-linux@vger.kernel.org,
felipe_life@live.com, linux-kernel@vger.kernel.org,
Lyude Paul <lyude@redhat.com>
Subject: Re: [PATCH v8] rust: add new macro for common bitflag operations
Date: Thu, 15 Jan 2026 14:31:58 +0100 [thread overview]
Message-ID: <87bjivf1dd.fsf@kernel.org> (raw)
In-Reply-To: <DFP6YJB8C5IG.3G4CMUM6YN45S@garyguo.net>
"Gary Guo" <gary@garyguo.net> writes:
> On Thu Jan 15, 2026 at 12:14 PM GMT, Andreas Hindborg wrote:
>> Andreas Hindborg <a.hindborg@kernel.org> writes:
>>
>>> "Filipe Xavier" <felipeaggger@gmail.com> writes:
>>>
>>>> We have seen a proliferation of mod_whatever::foo::Flags
>>>> being defined with essentially the same implementation
>>>> for BitAnd, BitOr, contains and etc.
>>>>
>>>> This macro aims to bring a solution for this,
>>>> allowing to generate these methods for user-defined structs.
>>>> With some use cases in KMS and upcoming GPU drivers.
>>>>
>>>> Link: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/We.20really.20need.20a.20common.20.60Flags.60.20type
>>>> Suggested-by: Daniel Almeida <daniel.almeida@collabora.com>
>>>> Suggested-by: Lyude Paul <lyude@redhat.com>
>>>> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
>>>> Reviewed-by: Lyude Paul <lyude@redhat.com>
>>>> Signed-off-by: Filipe Xavier <felipeaggger@gmail.com>
>>>
>>> Tested-by: Andreas Hindborg <a.hindborg@kernel.org>
>>> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
>>>
>>>
>>> I think it would be useful to add:
>>>
>>> impl Flags {
>>> unsafe from_raw(value: Repr) -> {
>>> ...
>>> }
>>> }
>>>
>>> impl TryFrom<Repr> for Flag {
>>> // Succeed if `value` is a valid `Flag` enum bit pattern.
>>> }
>>>
>>> impl TryFrom<Repr> for Flags {
>>> // Succeed if `value` is the logical OR of valid enum bit patterns.
>>> }
>>
>> Also bitwise operations on the underlying type such as
>>
>> impl BitOrAssign<Flag> for u32 {
>> ...
>> }
>>
>> Not sure if that is possible with the orphan rule, but it would be nice.
>> I was trying to
>>
>> lim.features |= request::Feature::Rotational;
>
> This is allowed by orphan rules, in a similar way that you can implement
> `From<Local> for Foreign`.
>
> However I don't think this is desirable feature? Why can't a conversion be used
> if you're using raw reprs?
>
> I think we should discourage the use of raw integers when bitflags can be used,
> adding that (or even `TryFrom`) can be a negative incentive.
In this case I have a C struct with a flag field. It would not be
ergonomic to read out the field, convert to `Flag` type, do the
operation, and store back again.
This assignment is in abstraction code. I could use the raw bindings
constant for the operation, but I would rather use the Rust type.
I do not think there is any risk by allowing operators between flags and
integers. What situation do you imagine where there would be a problem?
Best regards
Andreas Hindborg
next prev parent reply other threads:[~2026-01-15 13:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2JpjX5S1c2QLiHUftMzVViS7xatVGkJperCPqxJU8ZQ_Opyo4KPge5jcRCPb0Gcgyxb4yeFhm6Y-1X8q3pbNaw==@protonmail.internalid>
2026-01-11 13:32 ` [PATCH v8] rust: add new macro for common bitflag operations Filipe Xavier
2026-01-11 20:06 ` Miguel Ojeda
2026-01-11 21:47 ` Filipe Xavier
2026-01-15 12:09 ` Andreas Hindborg
2026-01-15 12:14 ` Andreas Hindborg
2026-01-15 12:49 ` Andreas Hindborg
2026-01-15 13:19 ` Gary Guo
2026-01-15 13:31 ` Andreas Hindborg [this message]
2026-01-15 13:45 ` Daniel Almeida
2026-01-15 19:03 ` Miguel Ojeda
2026-01-15 19:13 ` Daniel Almeida
2026-01-16 8:38 ` Andreas Hindborg
2026-01-15 13:39 ` Daniel Almeida
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bjivf1dd.fsf@kernel.org \
--to=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=felipe_life@live.com \
--cc=felipeaggger@gmail.com \
--cc=gary@garyguo.net \
--cc=linux-kernel@vger.kernel.org \
--cc=lyude@redhat.com \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.