Re: [PATCH v9 1/1] rust: pci: add extended capability and SR-IOV support

["Alexandre Courbot" <acourbot@nvidia.com>]

On Mon Aug 31, 2026 at 10:21 PM JST, Ilpo Järvinen wrote:
> On Thu, 27 Aug 2026, Zhi Wang wrote:
<...>
>> +crate::bitfield! {
>> +    /// Low DWORD of an SR-IOV VF BAR.
>> +    struct VfBarLow(u32) {
>
> I admit not knowing that much about Rust but this caught my eye...
>
> The PCIe spec says:
>
> "These fields must define the VF’s Base Address Registers (BARs). These 
> fields behave as normal PCI BARs, as described in § Section 7.5.1 ." 
>
> So why doesn't Rust just define this as "normal" BARs (given your naming 
> above, I'd expect simply "BarLow") but names it after "VF" specifically?
> Or does Rust require duplicating things in cases like this for namespacing 
> reasons?
>
> "BarLow" doesn't seem to exist under mainline's rust/, maybe that hasn't 
> been needed so far as C side code will likely be responsible for parsing 
> them.

Agreed, ultimately this BAR register should be defined in the PCI common
code so it can be used across the abstraction without being redefined.

This is not a Rust requirement and technically nothing prevents a common
declaration to be shared. It's more that we are still a bit in a phase
where we are figuring things out and where the ground is moving under
our feet (register definitions are still being actively worked on for
instance), so keeping it defined here at first may help reduce churn in
the end. But at the very least we can probably drop the `Vf` prefix from
its name (and from `VfBarMemoryType`) and add a `// TODO:` comment to
eventually move it to the PCI common code.

Unless Danilo already knows where he wants to take this, in which case
the register definition can be added in a separate patch.