All of lore.kernel.org
 help / color / mirror / Atom feed
From: Danilo Krummrich <dakr@kernel.org>
To: Gary Guo <gary@garyguo.net>
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 16:08:05 +0100	[thread overview]
Message-ID: <Z5EJ1Z4hbgQefuxX@pollux> (raw)
In-Reply-To: <20250122145653.4ce76a01.gary@garyguo.net>

On Wed, Jan 22, 2025 at 02:56:53PM +0000, Gary Guo wrote:
> 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

I think so too -- `Invariant` is the correct thing to use here.

But everywhere else in the kernel we phrase it differently. For instace, in
`Box` we say:

"`self.0` is always properly aligned and either points to memory allocated with
`A` or, for zero-sized types, is a dangling, well aligned pointer."

because this is ensured by the (safety requirements of the) constructor.

We don't say:

"`self.0` must be always properly aligned and either point to memory allocated
with `A` or, for zero-sized types, must be a dangling, well aligned pointer."

> uphold by the constructors (and only then it can be relied on). However
> the patch doesn't clearly indicate that.

  reply	other threads:[~2025-01-22 15:08 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
2025-01-22 15:08     ` Danilo Krummrich [this message]
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=Z5EJ1Z4hbgQefuxX@pollux \
    --to=dakr@kernel.org \
    --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=daniel.almeida@collabora.com \
    --cc=gary@garyguo.net \
    --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.