From: "Gary Guo" <gary@garyguo.net>
To: "Alexandre Courbot" <acourbot@nvidia.com>, "Gary Guo" <gary@garyguo.net>
Cc: "Danilo Krummrich" <dakr@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Daniel Almeida" <daniel.almeida@collabora.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Trevor Gross" <tmgross@umich.edu>,
"Boqun Feng" <boqun@kernel.org>,
"Yury Norov" <yury.norov@gmail.com>,
"John Hubbard" <jhubbard@nvidia.com>,
"Alistair Popple" <apopple@nvidia.com>,
"Joel Fernandes" <joelagnelf@nvidia.com>,
"Timur Tabi" <ttabi@nvidia.com>, "Edwin Peer" <epeer@nvidia.com>,
"Eliot Courtney" <ecourtney@nvidia.com>,
"Dirk Behme" <dirk.behme@de.bosch.com>,
"Steven Price" <steven.price@arm.com>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 05/10] rust: io: add IoLoc and IoWrite types
Date: Fri, 06 Mar 2026 11:35:59 +0000 [thread overview]
Message-ID: <DGVO2O009306.GNU06PZ13VA6@garyguo.net> (raw)
In-Reply-To: <DGVNJ8ANGP3Q.1RAGWU2HJGRIB@nvidia.com>
On Fri Mar 6, 2026 at 11:10 AM GMT, Alexandre Courbot wrote:
> On Fri Mar 6, 2026 at 7:42 PM JST, Gary Guo wrote:
>> On Fri Mar 6, 2026 at 5:37 AM GMT, Alexandre Courbot wrote:
>>> On Thu Mar 5, 2026 at 7:15 AM JST, Gary Guo wrote:
>>>> On Wed Mar 4, 2026 at 9:38 PM GMT, Danilo Krummrich wrote:
>>>>> On Wed Mar 4, 2026 at 10:13 PM CET, Gary Guo wrote:
>>>>>> Even for the cases where there's a PIO register, I think it's beneficial to just
>>>>>> get a value without a type.
>>>>>>
>>>>>> I don't see why we want people to write
>>>>>>
>>>>>> self.io.read(UART_RX).value()
>>>>>>
>>>>>> vs
>>>>>>
>>>>>> self.io.read(UART_RX)
>>>>>>
>>>>>> or
>>>>>>
>>>>>> self.io.write(UART_TX::from(byte))
>>>>>>
>>>>>> vs
>>>>>>
>>>>>> self.io.write(UART_TX, byte)
>>>>>>
>>>>>> what benefit does additional type provide?
>>>>>
>>>>> Well, for FIFO registers this is indeed better. However, my main concern was
>>>>> this
>>>>>
>>>>> bar.write(regs::MyReg, regs::MyReg::foo())
>>>>
>>>> This specific case is indeed more cumbersome with the two argument approach,
>>>> although given Alex's nova diff I think the occurance shouldn't be that
>>>> frequent.
>>>>
>>>> It's also not that the two argument approach would preclude us from having a
>>>> single argument option. In fact, with the two-argument design as the basis, we
>>>> can implement such a helper function cleaner than Alex's PATCH 10/10 (which uses
>>>> `Into<IoWrite>`:
>>>>
>>>> /// Indicates that this type is always associated with a specific fixed I/O
>>>> /// location.
>>>> ///
>>>> /// This allows use of `io.bikeshed_shorthand_name(value)` instead of specifying
>>>> /// the register name explicitly `io.write(REG, value)`.
>>>> trait FixedIoLocation {
>>>> type IoLocType: IoLoc<Self>;
>>>> const IO_LOCATION: Self::IoLocType;
>>>> }
>>>>
>>>> trait Io {
>>>> fn bikeshed_shorthand_name<T>(&self, value: T)
>>>> where T: FixedIoLocation +
>>>> Self: IoCapable<<T::IoLocType as IoLoc<T>>::IoType>,
>>>> {
>>>> self.write(T::IO_LOCATION, value)
>>>> }
>>>> }
>>>>
>>>> No need for a `IoWrite` type, everything is done via traits.
>>>
>>> That's cool but will only work for fixed registers. If you work with, say, an
>>> array of registers, cannot implement this trait on a value as the value
>>> doesn't have an index assigned - meaning you would have to build a
>>> location in addition of it.
>>
>> For array registers I think it makes more sense to use the two-argument version,
>> no?
>>
>> The example here is to demonstrate that we can add a shorthand version for the
>> fixed register version that can write a value to register without mentioning its
>> name (as a supplemental helper), and the basic write method is the two-argument
>> one.
>>
>> For cases where the type doesn't guarantee a fixed location like FIFO register
>> or an array register, mentioning the name twice is fine.
>
> It's still tedious, and a step back compared to the one-argument version
> imho.
>
>>
>> [
>>
>> For array case, you *could* also do
>>
>> impl IoLoc<RegisterName> for usize {
>> fn offset(self) -> usize {
>> self * stride + fixed_base
>> }
>> }
>>
>>
>> and now you can do `self.write(index, reg_value)`, although I think this
>> might confuse some people.
>
> Yes, in this case the semantics of write's first argument would be
> dependent on the second argument... I think that's a potential footgun.
I mean, `bar.write(Reg::at(10, regs::MyRegArray::foo()))` in your example is
also kind of "first argument depends on the second argument" situation, just
with a bit more boilerplate.
If you want to make things more explicit you could also have
`bar.write(at_array(10), ...)` or something similar.
For the array case I really think trying to shove everything into a single
argument is a footgun. The type of value in this case *doesn't* tell us the
location, and the location needs to be explicit.
Best,
Gary
>
>>
>> For the fixed case you could do
>>
>> impl IoLoc<RegisterName> for () {
>> fn offset(self) -> usize {
>> fixed_loc
>> }
>> }
>>
>> which means you can do `self.write((), value)`. I think this looks a bit
>> uglier compared to a dedicated method, but TBH it isn't too terrible.
>
> There is another potential solution I have played with:
>
> https://lore.kernel.org/all/DGVJ7VQX3TD5.2UYW004QJPI6N@nvidia.com/
>
> It would let us keep the 2-arguments as a base, while letting us take
> advantage of the one-argument syntax you proposed in [1] and extending
> it to support other register types.
>
> [1] https://lore.kernel.org/all/DGU9AZ43QK6Y.115RDSK0M9JY5@garyguo.net/
>
> I think it turns out pretty nice and the supporting code is also not too
> ugly. I'll try to send a diff a bit later so you can see how it behaves
> in practice.
next prev parent reply other threads:[~2026-03-06 11:36 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-24 14:21 [PATCH v7 00/10] rust: add `register!` macro Alexandre Courbot
2026-02-24 14:21 ` [PATCH v7 01/10] rust: enable the `generic_arg_infer` feature Alexandre Courbot
2026-02-24 14:21 ` [PATCH v7 02/10] rust: num: add `shr` and `shl` methods to `Bounded` Alexandre Courbot
2026-02-24 14:21 ` [PATCH v7 03/10] rust: num: add `into_bool` method " Alexandre Courbot
2026-02-24 14:21 ` [PATCH v7 04/10] rust: num: make Bounded::get const Alexandre Courbot
2026-02-27 12:33 ` Gary Guo
2026-02-24 14:21 ` [PATCH v7 05/10] rust: io: add IoLoc and IoWrite types Alexandre Courbot
2026-02-27 18:02 ` Gary Guo
2026-02-27 18:16 ` Danilo Krummrich
2026-02-28 0:33 ` Alexandre Courbot
2026-03-01 15:11 ` Gary Guo
2026-03-02 1:44 ` Alexandre Courbot
2026-03-02 12:53 ` Gary Guo
2026-03-02 13:12 ` Danilo Krummrich
2026-03-02 13:39 ` Gary Guo
2026-03-03 8:14 ` Alexandre Courbot
2026-03-03 8:31 ` Alexandre Courbot
2026-03-03 14:55 ` Alexandre Courbot
2026-03-03 15:05 ` Gary Guo
2026-03-04 16:18 ` Danilo Krummrich
2026-03-04 18:39 ` Gary Guo
2026-03-04 18:58 ` Gary Guo
2026-03-04 19:19 ` John Hubbard
2026-03-04 19:53 ` Danilo Krummrich
2026-03-04 19:57 ` John Hubbard
2026-03-04 20:05 ` Gary Guo
2026-03-04 19:38 ` Danilo Krummrich
2026-03-04 19:48 ` Gary Guo
2026-03-04 20:37 ` Danilo Krummrich
2026-03-04 21:13 ` Gary Guo
2026-03-04 21:38 ` Danilo Krummrich
2026-03-04 21:42 ` Danilo Krummrich
2026-03-04 22:15 ` Gary Guo
2026-03-04 22:22 ` Danilo Krummrich
2026-03-06 5:37 ` Alexandre Courbot
2026-03-06 7:47 ` Alexandre Courbot
2026-03-06 10:42 ` Gary Guo
2026-03-06 11:10 ` Alexandre Courbot
2026-03-06 11:35 ` Gary Guo [this message]
2026-03-06 12:50 ` Alexandre Courbot
2026-03-06 13:20 ` Gary Guo
2026-03-06 14:32 ` Alexandre Courbot
2026-03-06 14:52 ` Alexandre Courbot
2026-03-06 15:10 ` Alexandre Courbot
2026-03-06 15:35 ` Alexandre Courbot
2026-03-06 15:35 ` Gary Guo
2026-03-07 0:05 ` Alexandre Courbot
2026-03-07 21:10 ` Gary Guo
2026-03-07 21:40 ` Danilo Krummrich
2026-03-08 11:43 ` Alexandre Courbot
2026-03-08 11:35 ` Alexandre Courbot
2026-03-04 18:53 ` Gary Guo
2026-03-04 22:19 ` Gary Guo
2026-03-05 11:02 ` Alexandre Courbot
2026-02-24 14:21 ` [PATCH v7 06/10] rust: io: use generic read/write accessors for primitive accesses Alexandre Courbot
2026-02-27 18:04 ` Gary Guo
2026-02-24 14:21 ` [PATCH v7 07/10] rust: io: add `register!` macro Alexandre Courbot
2026-02-24 14:21 ` [PATCH v7 08/10] sample: rust: pci: use " Alexandre Courbot
2026-02-24 14:21 ` [PATCH FOR REFERENCE v7 09/10] gpu: nova-core: use the kernel " Alexandre Courbot
2026-02-24 14:21 ` [PATCH v7 10/10] RFC: rust: io: allow fixed register values directly in `write` Alexandre Courbot
2026-02-25 11:58 ` [PATCH v7 00/10] rust: add `register!` macro Dirk Behme
2026-02-25 13:50 ` Alexandre Courbot
2026-02-26 12:01 ` Dirk Behme
2026-02-27 23:30 ` Alexandre Courbot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DGVO2O009306.GNU06PZ13VA6@garyguo.net \
--to=gary@garyguo.net \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=dirk.behme@de.bosch.com \
--cc=ecourtney@nvidia.com \
--cc=epeer@nvidia.com \
--cc=jhubbard@nvidia.com \
--cc=joelagnelf@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=steven.price@arm.com \
--cc=tmgross@umich.edu \
--cc=ttabi@nvidia.com \
--cc=yury.norov@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®