On Tue Jun 16, 2026 at 7:58 PM JST, Gary Guo wrote:
> On Tue Jun 16, 2026 at 7:34 AM BST, Alexandre Courbot wrote:
>> On Fri Jun 12, 2026 at 1:28 AM JST, Gary Guo wrote:
>>> -/// The PCI configuration space of a device.
>>> +/// A view of PCI configuration space of a device.
>>> ///
>>> /// Provides typed read and write accessors for configuration registers
>>> /// using the standard `pci_read_config_*` and `pci_write_config_*`
>>> helpers.
>>> ///
>>> -/// The generic parameter `S` indicates the maximum size of the
>>> configuration space.
>>> -/// Use [`Normal`] for 256-byte legacy configuration space or [`Extended`]
>>> for
>>> -/// 4096-byte PCIe extended configuration space (default).
>>> -pub struct ConfigSpace<'a, S: ?Sized + ConfigSpaceKind = Extended> {
>>> +/// The generic parameter `T` is the type of the view. The full
>>> configuration space is also a
>>> +/// special type of view; in such cases, `T` can be [`Normal`] for
>>> 256-byte legacy configuration
>>> +/// space or [`Extended`] for 4096-byte PCIe extended configuration space
>>> (default).
>>> +///
>>> +/// # Invariants
>>> +///
>>> +/// `ptr` is aligned and range `ptr..ptr + KnownSize::size(ptr)` is within
>>> +/// `0..pdev.cfg_size().into_raw()`.
>>> +pub struct ConfigSpace<'a, T: ?Sized = Extended> {
>>> pub(crate) pdev: &'a Device<device::Bound>,
>>> - _marker: PhantomData<S>,
>>> + ptr: *mut T,
>>
>> `ptr` is used as a pseudo-pointer here, can its documentation be more
>> explicit about that?
>
> The invariant section is already hinting this by saying the pointer is
> between 0
> to cfg_size?
That's correct - I guess I am more worried by the fact that `addr` can
return values based on these pointers that are not dereferencable. The
problem (provided there is actually one) should be addressed there I
guess, I made a note about it in my review of the next patch.
