lkml.org 
[lkml]   [2024]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 10/11] rust: add basic abstractions for iomem operations
On Tue, May 21, 2024 at 11:18:04AM +0200, Miguel Ojeda wrote:
> On Tue, May 21, 2024 at 9:36 AM Philipp Stanner <pstanner@redhat.com> wrote:
> >
> > Justified questions – it is public because the Drop implementation for
> > pci::Bar requires the ioptr to pass it to pci_iounmap().
> >
> > The alternative would be to give pci::Bar a copy of ioptr (it's just an
> > integer after all), but that would also not be exactly beautiful.
>
> If by copy you mean keeping an actual copy elsewhere, then you could
> provide an access method instead.

As mentioned earlier, given the context how we use IoMem, I think IoMem should
just be a trait. And given that, maybe we'd want to name this trait differently
then, something like `trait IoOps` maybe?

pub trait IoOps {
// INVARIANT: The implementation must ensure that the returned value is
// either an error code or a non-null and valid address suitable for I/O
// operations of the given offset and length.
fn io_addr(&self, offset: usize, len: usize) -> Result<usize>;

fn readb(&self, offset: usize) -> Result<u8> {
let addr = self.io_addr(offset, 1)?;

// SAFETY: `addr` is guaranteed to be valid as by the invariant required
// by `io_addr`.
Ok(unsafe { bindings::readb(addr as _) })
}

[...]
}

We can let the resource type (e.g. `pci::Bar`) track the base address and limit
instead and just let pci::Bar implement `IoMem::io_addr`.

As for the compile time size, this would be up the the actual resource then.
`pci::Bar` can't make use of this optimization, while others might be able to.

Does that sound reasonable?

- Danilo


\
 
 \ /
  Last update: 2024-05-21 20:36    [W:0.101 / U:0.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site