From: Zhi Wang <zhiw@nvidia.com>
To: Zijing Zhang <zijing.zhang@ry.rs>
Cc: Gary Guo <gary@garyguo.net>, <dakr@kernel.org>,
<linux-pci@vger.kernel.org>, <rust-for-linux@vger.kernel.org>,
<bhelgaas@google.com>, <kwilczynski@kernel.org>,
<ojeda@kernel.org>, <dirk.behme@gmail.com>, <lianux.mm@gmail.com>
Subject: Re: [PATCH v5 0/2] rust: pci: add capability lookup helpers
Date: Mon, 2 Feb 2026 21:57:15 +0200 [thread overview]
Message-ID: <20260202215715.1000e2eb.zhiw@nvidia.com> (raw)
In-Reply-To: <2f385010-0a47-4d0f-8554-b841f6026561@ry.rs>
On Mon, 2 Feb 2026 23:41:42 +0800
Zijing Zhang <zijing.zhang@ry.rs> wrote:
>
>
Hi Zijing,
Good to see you working on this too! Welcome to join the party!
I think "thin wrappers" were indeed the initial thought for many of us.
However, after several rounds of discussions with maintainers at the
summits, the requirement has shifted towards a stricter, OO-style Rust
abstraction rather than direct wrappers.
The key takeaways for the current direction are:
- Enforcing boundary checks via the Io trait backend.
- Using register! macros for definitions.
- Implementing proper Rust iterators for Cap discovery.
Since nova-core relies on these specific safety features, I'm pushing
forward with this high-level abstraction. For nova-core, our immediate
need is accessing and reading registers in the SR-IOV capability.
That said, there is plenty of room for collaboration to achieve a complete
framework! For example, support for normal configuration space
capabilities, the iterator implementation itself, and capabilities other
than SR-IOV are all areas that need work.
Currently, I am waiting for Alex's Io trait cleanup and refactor to settle
before deciding what should be included or changed in my next re-spin.
Also, any input on how to best organize the traits between normal
configuration space caps and extended caps would be much appreciated!
You are also welcome to reach out via Zulip for a quick discussion or
catch-up.
Z.
> On 2/2/2026 11:02 PM, Gary Guo wrote:
> > On Sun Feb 1, 2026 at 7:42 AM GMT, Zijing Zhang wrote:
> >> It introduces `pci::Device::{find_capability, find_ext_capability}`,
> >> thin wrappers around the PCI core helpers (`pci_find_capability()` and
> >> `pci_find_ext_capability()`), returning the config-space offset when
> >> present.
> >>
> >> In `pci::CapabilityId` and `pci::ExtendedCapabilityId`, Capability
> >> IDs are wrapped as newtypes with `from_raw()` plus a set of common
> >> constants.
> >>
> >> An in-tree user is added to Rust PCI driver sample to exercise the
> >> new API.
> >>
> >> Previous versions (v4)
> >> https://lore.kernel.org/rust-for-linux/20260201071450.1614172-1-zijing.zhang@ry.rs/
> >
> > Also I'd like to mention that Zhi Wang already have a version adding
> > the same feature on the list, sent before your v1:
> >
> > https://lore.kernel.org/rust-for-linux/20260126215957.541180-3-zhiw@nvidia.com/
> >
> > I'd recommend to work together for the feature rather than creating
> > competing series.
> >
> > Thanks,
> > Gary
> >
> >>
> >> Testing
> >> ---
> >>
> >> Build
> >> - x86_64 defconfig-based kernel with Rust enabled (out-of-tree build)
> >> - `CONFIG_SAMPLES_RUST=y`
> >> - `CONFIG_SAMPLE_RUST_DRIVER_PCI=y`
> >>
> >> Runtime
> >> - QEMU x86_64 (i440FX) with `-device pci-testdev`
> >> - QEMU x86_64 (q35) with an NVMe device
> >>
> >> Changelog
> >> ---
> >>
> >> v2
> >> - Run rustfmt on samples/rust/rust_driver_pci.rs to fix rustfmtcheck.
> >>
> >> v3
> >> - Base on pci/next.
> >> - Add `CapabilityId`/`ExtendedCapabilityId`, switch
> >> `find_*capability()` to use them.
> >> - Document the common ID constants.
> >> - Update the sample to use typed IDs and exercise the new helpers.
> >>
> >> v4
> >> - Minor doc/style nits.
> >> - Use early-return style in `find_*capability()`.
> >>
> >>
> >> v5 (current)
> >> - Fix sample build by using `pdev.as_ref()` for `dev_info!`.
> >> - Use `as _` in constant definitions.
> >>
> >> Zijing Zhang (2):
> >> rust: pci: add capability lookup helpers
> >> samples: rust: pci: exercise capability lookup
> >>
> >> rust/kernel/pci.rs | 150
> >> ++++++++++++++++++++++++++++++++ samples/rust/rust_driver_pci.rs |
> >> 31 +++++++ 2 files changed, 181 insertions(+)
> >>
> >>
> >> base-commit: ff0e2f679ab0de50a2e9e88fabc1026bc3be04ba
> >
>
>
> On 2/2/2026 11:02 PM, Gary Guo wrote:
> > On Sun Feb 1, 2026 at 7:42 AM GMT, Zijing Zhang wrote:
> >> It introduces `pci::Device::{find_capability, find_ext_capability}`,
> thin
> >> wrappers around the PCI core helpers (`pci_find_capability()` and
> >> `pci_find_ext_capability()`), returning the config-space offset when
> present.
> >>
> >> In `pci::CapabilityId` and `pci::ExtendedCapabilityId`, Capability
> IDs are
> >> wrapped as newtypes with `from_raw()` plus a set of common constants.
> >>
> >> An in-tree user is added to Rust PCI driver sample to exercise the
> new API.
> >>
> >> Previous versions (v4)
> >>
> https://lore.kernel.org/rust-for-linux/20260201071450.1614172-1-zijing.zhang@ry.rs/
> >
> > Also I'd like to mention that Zhi Wang already have a version adding
> the same
> > feature on the list, sent before your v1:
> >
> >
> https://lore.kernel.org/rust-for-linux/20260126215957.541180-3-zhiw@nvidia.com/
> >
> > I'd recommend to work together for the feature rather than creating
> competing
> > series.
> >
> > Thanks,
> > Gary
> >
> >>
> >> Testing
> >> ---
> >>
> >> Build
> >> - x86_64 defconfig-based kernel with Rust enabled (out-of-tree build)
> >> - `CONFIG_SAMPLES_RUST=y`
> >> - `CONFIG_SAMPLE_RUST_DRIVER_PCI=y`
> >>
> >> Runtime
> >> - QEMU x86_64 (i440FX) with `-device pci-testdev`
> >> - QEMU x86_64 (q35) with an NVMe device
> >>
> >> Changelog
> >> ---
> >>
> >> v2
> >> - Run rustfmt on samples/rust/rust_driver_pci.rs to fix rustfmtcheck.
> >>
> >> v3
> >> - Base on pci/next.
> >> - Add `CapabilityId`/`ExtendedCapabilityId`, switch
> >> `find_*capability()` to use them.
> >> - Document the common ID constants.
> >> - Update the sample to use typed IDs and exercise the new helpers.
> >>
> >> v4
> >> - Minor doc/style nits.
> >> - Use early-return style in `find_*capability()`.
> >>
> >>
> >> v5 (current)
> >> - Fix sample build by using `pdev.as_ref()` for `dev_info!`.
> >> - Use `as _` in constant definitions.
> >>
> >> Zijing Zhang (2):
> >> rust: pci: add capability lookup helpers
> >> samples: rust: pci: exercise capability lookup
> >>
> >> rust/kernel/pci.rs | 150
> >> ++++++++++++++++++++++++++++++++ samples/rust/rust_driver_pci.rs |
> >> 31 +++++++ 2 files changed, 181 insertions(+)
> >>
> >>
> >> base-commit: ff0e2f679ab0de50a2e9e88fabc1026bc3be04ba
> >
>
> Hi Gary and all,
>
> Thanks for the feedback.
>
> Zhi's work on SR-IOV is excellent and provides a higher-level
> abstraction. My series focuses on providing the fundamental lookup
> infrastructure and typed IDs, which are intended to serve as a
> general-purpose foundation for any PCI capability interaction.
>
> These two series appear to be complementary. I am open to any
> integration path the maintainers prefer and would welcome Zhi's thoughts
> on how we might best align these efforts.
>
> As a newcomer to the community, I am passionate about Rust PCI driver
> development and appreciate Gary's diligence in maintaining the
> subsystem's quality. I've taken note of the feedback regarding the patch
> frequency and will ensure to allow more time for review in future
> iterations.
>
> Thanks,
> Zijing
>
next prev parent reply other threads:[~2026-02-02 19:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-01 7:42 [PATCH v5 0/2] rust: pci: add capability lookup helpers Zijing Zhang
2026-02-01 7:42 ` [PATCH v5 1/2] " Zijing Zhang
2026-02-01 7:42 ` [PATCH v5 2/2] samples: rust: pci: exercise capability lookup Zijing Zhang
2026-02-02 14:13 ` [PATCH v5 0/2] rust: pci: add capability lookup helpers Gary Guo
2026-02-02 15:02 ` Gary Guo
2026-02-02 15:41 ` Zijing Zhang
2026-02-02 19:57 ` Zhi Wang [this message]
2026-02-03 5:42 ` Zijing Zhang
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=20260202215715.1000e2eb.zhiw@nvidia.com \
--to=zhiw@nvidia.com \
--cc=bhelgaas@google.com \
--cc=dakr@kernel.org \
--cc=dirk.behme@gmail.com \
--cc=gary@garyguo.net \
--cc=kwilczynski@kernel.org \
--cc=lianux.mm@gmail.com \
--cc=linux-pci@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=zijing.zhang@ry.rs \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox