[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <DG79GRI3NOLS.3ASMS9RJ80IXM@kernel.org>
Date: Thu, 05 Feb 2026 20:05:08 +0100
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Daniel Almeida" <daniel.almeida@...labora.com>
Cc: "Gary Guo" <gary@...yguo.net>, "Link Mauve" <linkmauve@...kmauve.fr>,
<rust-for-linux@...r.kernel.org>, "Madhavan Srinivasan"
<maddy@...ux.ibm.com>, "Michael Ellerman" <mpe@...erman.id.au>, "Nicholas
Piggin" <npiggin@...il.com>, "Christophe Leroy (CS GROUP)"
<chleroy@...nel.org>, "Srinivas Kandagatla" <srini@...nel.org>, "Miguel
Ojeda" <ojeda@...nel.org>, "Boqun Feng" <boqun@...nel.org>,
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>, "Ard
Biesheuvel" <ardb@...nel.org>, "Martin K. Petersen"
<martin.petersen@...cle.com>, "Eric Biggers" <ebiggers@...gle.com>, "Greg
Kroah-Hartman" <gregkh@...uxfoundation.org>, "Lyude Paul"
<lyude@...hat.com>, "Asahi Lina" <lina+kernel@...hilina.net>, "Viresh
Kumar" <viresh.kumar@...aro.org>, "Lorenzo Stoakes"
<lorenzo.stoakes@...cle.com>, "Tamir Duberstein" <tamird@...nel.org>,
"FUJITA Tomonori" <fujita.tomonori@...il.com>,
<linuxppc-dev@...ts.ozlabs.org>, <linux-kernel@...r.kernel.org>,
<officialTechflashYT@...il.com>, "Ash Logan" <ash@...quark.com>, "Roberto
Van Eeden" <rw-r-r-0644@...tonmail.com>,
Jonathan Neuschäfer <j.neuschaefer@....net>
Subject: Re: [PATCH v2 1/4] rust: io: Add big-endian read and write
functions
On Thu Feb 5, 2026 at 6:28 PM CET, Daniel Almeida wrote:
>> On 5 Feb 2026, at 12:16, Gary Guo <gary@...yguo.net> wrote:
>> I think we should have everything default to little endian, and have wrapper
>> types that do big endian which require expicit construction, similar to
>> RelaxedMmio in Alex's series.
>
> Ah yes, the RelaxedMmio pattern is definitely a good one. I agree that we
> should head in this direction.
I strongly disagree.
This is a great pattern for relaxed ordering because:
(1) We need both strict and relaxed ordering.
(2) Relaxed ordering is rare, hence it doesn't hurt to write e.g.
io.relaxed().write()
(3) If you by accident just write
io.write()
i.e. forget to call relaxed() it s not a bug, nothing bad happens.
Whereas for endianness it is a bad pattern because:
(1) Devices are either little-endian or big-endian. Hence, having to write
io.big_endian().write()
is excessive, we always want big-endian for a big-endian device.
(2) It is error prone, if you forget to call big_endian() first, it is a bug.
(3) It is unergonomic in combination with relaxed ordering.
io.big_endian().relaxed().write()
(Does the other way around work as well? :)
It makes much more sense to define once when we request the I/O memory whether
the device is litte-endian or big-endian.
This could be done with different request functions, a const generic or a
function argument, but it should be done at request time.
Powered by blists - more mailing lists