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: <CANiq72ny=huNUmM7_1XjFyXZ_zvTFiAGwx4UB_dOxSaUx5VwOg@mail.gmail.com>
Date: Tue, 20 Jan 2026 16:48:15 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Danilo Krummrich <dakr@...nel.org>
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: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 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?

> 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.

> You mean a tag with the bitfield!() code? Yeah, that would help if we don't make
> it this cycle.

Yeah.

Cheers,
Miguel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ