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: <DFTOMX7KEFXK.3A9467KZ5GGAG@kernel.org>
Date: Tue, 20 Jan 2026 21:01:08 +0100
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Miguel Ojeda" <miguel.ojeda.sandonis@...il.com>
Cc: "Alexandre Courbot" <acourbot@...dia.com>, "Miguel Ojeda"
 <ojeda@...nel.org>, "Boqun Feng" <boqun.feng@...il.com>, "Gary Guo"
 <gary@...yguo.net>, Björn Roy Baron
 <bjorn3_gh@...tonmail.com>, "Benno Lossin" <lossin@...nel.org>, "Andreas
 Hindborg" <a.hindborg@...nel.org>, "Alice Ryhl" <aliceryhl@...gle.com>,
 "Trevor Gross" <tmgross@...ch.edu>, "Yury Norov" <yury.norov@...il.com>,
 "John Hubbard" <jhubbard@...dia.com>, "Alistair Popple"
 <apopple@...dia.com>, "Joel Fernandes" <joelagnelf@...dia.com>, "Timur
 Tabi" <ttabi@...dia.com>, "Edwin Peer" <epeer@...dia.com>, "Eliot Courtney"
 <ecourtney@...dia.com>, "Daniel Almeida" <daniel.almeida@...labora.com>,
 "Dirk Behme" <dirk.behme@...bosch.com>, "Steven Price"
 <steven.price@....com>, <rust-for-linux@...r.kernel.org>,
 <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/6] rust: add `bitfield!` and `register!` macros

On Tue Jan 20, 2026 at 4:48 PM CET, Miguel Ojeda wrote:
> On Tue, Jan 20, 2026 at 4:27 PM Danilo Krummrich <dakr@...nel.org> wrote:
>>
>> I think it's just about pasting the current bitfield work into register.rs, such
>> that it can only be used from there. In a follow up we can work out how it
>> should turn out finally and have to patches: 1. introduce bitfield.rs and 2.
>> move register!() to use the code from bitfield.rs.
>
> Hmm... I am generally not a fan of putting local code. I know you did
> it for the DRM `register!` itself, which is fine given the constraints
> you have, but here perhaps we could put it in the right file but as
> private/hidden as possible just to be used by the other file?
>
> i.e. that way we can debate improvements on top of what we have,
> rather than having a move or new code and a drop of the old one?

I'm fine either way; the reason I proposed it the way I did was that I think it
sets the least precedence for how bitfields should turn out eventually.

> I mention this since you say "pasting", i.e. I guess it is still
> smaller, but it sounds like you would essentially use it more or less
> as-is?

I left this to Alex, he knows best what makes sense.

>> The register!() macro code is worked on by Alex for about 10 month in nova-core,
>> the first RFC for general I/O infrastructure is from March 2025 and the current
>> series has been discussed on the list for about two cycles.
>
> I meant the `bitfield!` one, i.e. landing the patches as they are here
> if we get very fast agreement etc. etc. I can see that possibility,
> especially if private/hidden.

I think it's rather unlikely to land bitfields this cycle. I think Yury
explicitly requested more discussion on bitfields and also encouraged the "two
stage" approach [1] moving register!() first and then extract bitfields
subsequently.

[1] https://lore.kernel.org/lkml/aOaIIV8KDA0GjF6E@yury/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ