linux-kernel - Re: [PATCH v9 2/5] rust: io: factor common I/O helpers into Io trait

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: <DFQ1O2M9YEDC.3HOIZKNM4HDVF@kernel.org>
Date: Fri, 16 Jan 2026 14:23:12 +0100
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Alice Ryhl" <aliceryhl@...gle.com>
Cc: "Zhi Wang" <zhiw@...dia.com>, <rust-for-linux@...r.kernel.org>,
 <linux-pci@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
 <bhelgaas@...gle.com>, <kwilczynski@...nel.org>, <ojeda@...nel.org>,
 <alex.gaynor@...il.com>, <boqun.feng@...il.com>, <gary@...yguo.net>,
 <bjorn3_gh@...tonmail.com>, <lossin@...nel.org>, <a.hindborg@...nel.org>,
 <tmgross@...ch.edu>, <markus.probst@...teo.de>, <helgaas@...nel.org>,
 <cjia@...dia.com>, <smitra@...dia.com>, <ankita@...dia.com>,
 <aniketa@...dia.com>, <kwankhede@...dia.com>, <targupta@...dia.com>,
 <acourbot@...dia.com>, <joelagnelf@...dia.com>, <jhubbard@...dia.com>,
 <zhiwang@...nel.org>, <daniel.almeida@...labora.com>
Subject: Re: [PATCH v9 2/5] rust: io: factor common I/O helpers into Io
 trait

On Fri Jan 16, 2026 at 11:44 AM CET, Alice Ryhl wrote:
> On Thu, Jan 15, 2026 at 11:26:46PM +0200, Zhi Wang wrote:
>> +pub trait IoBase {
>> +pub trait IoKnownSize: IoBase {
>> +pub trait Io: IoBase {
>> +pub trait IoKnownSize64: IoKnownSize {
>> +pub trait Io64: Io {
>
> The following combinations are possible:
>
> 1. IoBase
> 2. IoBase + Io
> 3. IoBase + IoKnownSize
> 4. IoBase + Io + IoKnownSize
> 5. IoBase + Io + Io64
> 6. IoBase + Io + Io64 + IoKnownSize
> 7. IoBase + IoKnownSize + IoKnownSize64
> 8. IoBase + Io + IoKnownSize + IoKnownSize64
> 9. IoBase + Io + IoKnownSize + Io64 + IoKnownSize64
>
> I'm not sure all of them make sense. I can't see a scenario where I
> would pick 1, 3, 6, 7, or 8.

I think for the PCI configuration space backend we can get away with 3
(which implies that the others have to exist as well).

However - and I think I already mentioned this in previous reply a while ago - I
am not insisting to make this split for this reason, as it is an exception
rather than the rule.

However, note that the only really odd one is 1. All other ones could exist when
there is simply no user for certain accessors, i.e. they would be dead code.

Having that said, I think both have rather minor advantages and disadvantes, so
I'm fine with either. If you feel strongly about this, let's go with your
proposal below.

> How about this trait hierachy? I believe I suggested something along
> these lines before.
>
> pub trait Io {
> pub trait Io64: Io {
> pub trait IoKnownSize: Io {
>
> With these traits, these scenarios are possible:
>
> 1. Io
> 2. Io + Io64
> 3. Io + IoKnownSize
> 4. Io + Io64 + IoKnownSize
>
> which seems to be the actual set of cases we care about.
>
> Note that IoKnownSize can have methods that only apply when Io64 is
> implemented:
>
> trait IoKnownSize: Io {
>     /// Infallible 8-bit read with compile-time bounds check.
>     fn read8(&self, offset: usize) -> u8;
>
>     /// Infallible 64-bit read with compile-time bounds check.
>     fn read64(&self, offset: usize) -> u64
>     where
>     	Self: Io64;
> }
>
> Alice