linux-kernel - Re: [PATCH v2 1/4] rust: io: Add big-endian read and write functions

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aYUJuF8bI7mwD4ON@luna>
Date: Thu, 5 Feb 2026 22:20:56 +0100
From: Link Mauve <linkmauve@...kmauve.fr>
To: Danilo Krummrich <dakr@...nel.org>
Cc: Daniel Almeida <daniel.almeida@...labora.com>,
	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 05, 2026 at 08:05:08PM +0100, Danilo Krummrich wrote:
> 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.

Could this ever be done in the device tree?  I understand this would
mean having to change all drivers and all device trees that do big
endian, but it seems to be the natural location for this information.  I
have no idea how to structure that though.

-- 
Link Mauve