[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiq72n96fJScyVr5eWrfTu8WE9dWXNoyTaLr-CuFj30E57RdQ@mail.gmail.com>
Date: Tue, 28 Jan 2025 19:55:04 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: gtimothy-dev@...tonmail.com
Cc: Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>,
Andreas Hindborg <a.hindborg@...nel.org>, Boqun Feng <boqun.feng@...il.com>,
Gary Guo <gary@...yguo.net>, Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Benno Lossin <benno.lossin@...ton.me>, Alice Ryhl <aliceryhl@...gle.com>,
Trevor Gross <tmgross@...ch.edu>, rust-for-linux@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] rust: HrTimerMode replacement with bitfield_options macro
On Tue, Jan 28, 2025 at 6:13 PM Timothy Garwood via B4 Relay
<devnull+gtimothy-dev.protonmail.com@...nel.org> wrote:
>
> This patch provides an example of usage of the bitfield_options macro
> proposed in [1] as a replacement for the HrTimerMode enum introduced in
> [2].
> [1] is a RFC.
> This patch depends on both [1] and [2]
This is great, that is exactly what I was thinking about, and
showcases the advantage indeed :)
One quick question: what happens with the generated docs of the enum
and each variant etc.? (since that is part of the savings in lines
here)
Nits/tips: when you send the next version, consider sending both as a
series, i.e. this patch being #2 in the series, and #1 the one the
"real patch" that introduces the macro. That way they stay linked and
people browsing their emails and/or Lore will see it together :)
Also, the notes on the commit that are not part of the commit should
go after the SoB and the `---` line, before the diffstat.
There is also some strange text wrapping going on in the message, e.g.
on the `Link:` lines.
Cheers,
Miguel
Powered by blists - more mailing lists