Messages in this thread | | | Date | Tue, 21 May 2024 20:36:36 +0200 | From | Danilo Krummrich <> | Subject | Re: [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
| |