linux-kernel - Re: [PATCH v4 5/7] rust: io: add `register!` macro

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] [day] [month] [year] [list]

Message-ID: <20260128175605.GA2175960@joelbox2>
Date: Wed, 28 Jan 2026 12:56:05 -0500
From: Joel Fernandes <joelagnelf@...dia.com>
To: Alexandre Courbot <acourbot@...dia.com>
Cc: John Hubbard <jhubbard@...dia.com>, Danilo Krummrich <dakr@...nel.org>,
	Alice Ryhl <aliceryhl@...gle.com>,
	Daniel Almeida <daniel.almeida@...labora.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>,
	Trevor Gross <tmgross@...ch.edu>, Yury Norov <yury.norov@...il.com>,
	Alistair Popple <apopple@...dia.com>, Timur Tabi <ttabi@...dia.com>,
	Edwin Peer <epeer@...dia.com>,
	Eliot Courtney <ecourtney@...dia.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 v4 5/7] rust: io: add `register!` macro

On Wed, 28 Jan 2026, Alexandre Courbot wrote:
> So these setters are really part of the `bitfield!` API. Bitfields are,
> at the end of the day, just integers which we will very likely want to
> declare constants of out of individual const field values. This can only
> be done by using const methods, and a const `Bounded` needs to validate
> its constraints at build time, which requires the
> `Bounded::new::<VALUE>()` constructor, and by transition
> similarly-shaped setters to set fields at const time.

I think you run into that issue because the setter requires to do `.into()`
to do the bounded conversion.

If we accept Bounded type in the setter directly instead, it
should allow to keep the API simple. The advantage is it keeps the API naming
simple. with_<field>() which accepts Bounded type, that's the contract. The
trade off is the call-site can be a bit more icky but I wonder how much of an
issue that really is (it really depends on usage).

I wrote a simple program to confirm the same function will work for both const
and non-const parameters. Actually the caller does not even need to specific
the bounded int size at the call site, it gets inferred. So we don't even need
a bounded! macro.

struct Bounded<const BITS: u32>(u32);
impl<const BITS: u32> Bounded<BITS> {
    pub const fn new<const VAL: u32>() -> Self { Self(VAL) }
    pub fn try_new(val: u32) -> Result<Self, Error> { Ok(Self(val)) }
}

struct Reg(u32);
impl Reg {
    pub const fn with_foo(self, b: Bounded<4>) -> Self { Self(b.0) }
}

fn bar() -> Result {
    const C: Reg = Reg(0).with_foo(Bounded::new::<7>());  // const
    let r = Reg(0).with_foo(Bounded::try_new(9)?);        // runtime
    println!("{} {}", C.0, r.0);
    Ok(())
}

This is clean IMO. Additionally, bounded! and bounded_expr! could be provided
to build the bounded types.

Thoughts?

--
Joel Fernandes