All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gary Guo <gary@garyguo.net>
To: Danilo Krummrich <dakr@kernel.org>
Cc: "Fiona Behrens" <me@kloenk.dev>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <benno.lossin@proton.me>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rust: io: move offset_valid and io_addr(_assert) to IoRaw
Date: Wed, 22 Jan 2025 14:56:53 +0000	[thread overview]
Message-ID: <20250122145653.4ce76a01.gary@garyguo.net> (raw)
In-Reply-To: <Z5D_IxCZvcZ_jKd8@pollux>

On Wed, 22 Jan 2025 15:22:27 +0100
Danilo Krummrich <dakr@kernel.org> wrote:

> On Wed, Jan 22, 2025 at 01:38:09PM +0100, Fiona Behrens wrote:
> > Move the helper functions `offset_valid`, `io_addr` and
> > `io_addr_asset` from `Io` to `IoRaw`. This allows `IoRaw` to be reused
> > if other abstractions with different write/read functions are
> > needed (e.g. `writeb` vs `iowrite` vs `outb`).
> > 
> > Make this functions public as well so they can be used from other
> > modules if you aquire a `IoRaw`.  
> 
> I don't think they should be public. Instead the abstraction for I/O ports
> should be in this file, just like `Io` is.
> 
> Another option could also be to just extend the existing `Io` abstraction for
> I/O ports.
> 
> > 
> > Signed-off-by: Fiona Behrens <me@kloenk.dev>
> > ---
> >  rust/kernel/io.rs | 98 +++++++++++++++++++++++++++++++++++--------------------
> >  1 file changed, 63 insertions(+), 35 deletions(-)
> > 
> > diff --git a/rust/kernel/io.rs b/rust/kernel/io.rs
> > index d4a73e52e3ee68f7b558749ed0108acde92ae5fe..a6d026f458608626113fd194ee5a8616b4ef76fe 100644
> > --- a/rust/kernel/io.rs
> > +++ b/rust/kernel/io.rs
> > @@ -15,6 +15,11 @@
> >  /// Instead, the bus specific MMIO implementation must convert this raw representation into an `Io`
> >  /// instance providing the actual memory accessors. Only by the conversion into an `Io` structure
> >  /// any guarantees are given.
> > +///
> > +/// # Invariant  
> 
> You phrased this invariant as if it would be a requirement, but it's more like a
> something that's always uphold. I'd phrase it as a fact that can be relied on.

I thinkt the use of `Invariant` here is correct, as this needs to be
uphold by the constructors (and only then it can be relied on). However
the patch doesn't clearly indicate that.

> 
> > +///
> > +/// `addr` plus `maxsize` has to fit in memory (smaller than [`usize::MAX`])  
> 
> "fit in memory" sounds a bit misleading. I think you want to say they have to be
> in the range of some address space (e.g. PIO).
> 
> Besides that, why do we need this at all in this patch? I think it's fine to
> add, but then it should be separate patch I think.
> 
> > +/// and `maxsize` has to be smaller or equal to `SIZE`.  
> 
> That's wrong, it's the other way around.

Yeah, this is wrong.

> 
> >  pub struct IoRaw<const SIZE: usize = 0> {
> >      addr: usize,
> >      maxsize: usize,
> > @@ -23,7 +28,7 @@ pub struct IoRaw<const SIZE: usize = 0> {
> >  impl<const SIZE: usize> IoRaw<SIZE> {
> >      /// Returns a new `IoRaw` instance on success, an error otherwise.
> >      pub fn new(addr: usize, maxsize: usize) -> Result<Self> {
> > -        if maxsize < SIZE {
> > +        if maxsize < SIZE || addr.checked_add(maxsize).is_none() {
> >              return Err(EINVAL);
> >          }

Best,
Gary

  reply	other threads:[~2025-01-22 14:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-22 12:38 [PATCH] rust: io: move offset_valid and io_addr(_assert) to IoRaw Fiona Behrens
2025-01-22 14:22 ` Danilo Krummrich
2025-01-22 14:56   ` Gary Guo [this message]
2025-01-22 15:08     ` Danilo Krummrich
2025-01-28 11:11   ` Fiona Behrens
2025-01-22 14:55 ` Gary Guo

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=20250122145653.4ce76a01.gary@garyguo.net \
    --to=gary@garyguo.net \
    --cc=a.hindborg@kernel.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=benno.lossin@proton.me \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=me@kloenk.dev \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tmgross@umich.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.