linux-kernel - Re: [PATCH] rust: platform: add Io support

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: <CAH5fLgiirkt-JOF3XWNAyEFWZ=nGBPumqVVBOc_-PvfqriD-fw@mail.gmail.com>
Date: Tue, 5 Nov 2024 11:09:36 +0100
From: Alice Ryhl <aliceryhl@...gle.com>
To: Daniel Almeida <daniel.almeida@...labora.com>
Cc: Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, 
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Benno Lossin <benno.lossin@...ton.me>, Andreas Hindborg <a.hindborg@...nel.org>, 
	Trevor Gross <tmgross@...ch.edu>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, 
	"Rafael J. Wysocki" <rafael@...nel.org>, rust-for-linux@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rust: platform: add Io support

On Mon, Nov 4, 2024 at 10:28 PM Daniel Almeida
<daniel.almeida@...labora.com> wrote:
>
> Hi Alice!
>
> > On 29 Oct 2024, at 10:46, Alice Ryhl <aliceryhl@...gle.com> wrote:
> >
> > On Mon, Oct 28, 2024 at 7:23 PM Daniel Almeida
> > <daniel.almeida@...labora.com> wrote:
> >>
> >> Hi Alice,
> >>
> >>> On 28 Oct 2024, at 12:37, Alice Ryhl <aliceryhl@...gle.com> wrote:
> >>>
> >>> On Thu, Oct 24, 2024 at 4:20 PM Daniel Almeida
> >>> <daniel.almeida@...labora.com> wrote:
> >>>> +    /// Returns the resource len for `resource`, if it exists.
> >>>> +    pub fn resource_len(&self, resource: u32) -> Result<bindings::resource_size_t> {
> >>>
> >>> Should this just return usize? Should we have a type alias for this size type?
> >>
> >>
> >> I guess usize would indeed be a better fit, if we consider the code below:
> >>
> >> ```
> >> #ifdef CONFIG_PHYS_ADDR_T_64BIT
> >> typedef u64 phys_addr_t;
> >> #else
> >> typedef u32 phys_addr_t;
> >> #endif
> >>
> >> typedef phys_addr_t resource_size_t;
> >
> > Hmm. I guess they probably do that because phys_addr_t could differ
> > from size_t? Sounds like we may want a typedef called phys_addr_t
> > somewhere on the Rust side?
>
>
> By the way, I wonder if that connects with Gary’s work on unifying the bindgen
> primitives somehow.
>
>
> I think that having a #ifdef for `phys_addr_t` is pretty self-explanatory, but I have no
> idea why this is not simply `size_t`. My understanding is that `size_t` and `phys_addr_t`
> should be basically interchangeable, in the sense that, for example, a 32bit machine can
> only address up to 0xffffffff, and, by extension, can only have objects that are 0xffffffff in size
> at maximum.
>
> This behavior is identical to usize, unless I missed something.
>
> Maybe more knowledgeable people than me can chime in here?

It seems PHYS_ADDR_T_64BIT can be set even on some 32-bit machines.
See config HIGHMEM64G for 32-bit processors with more than 4 GB of
physical ram.

Alice