From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: samples: rust: add SR-IOV driver sample Date: Wed, 04 Mar 2026 08:40:17 +1000 Message-ID: In-Reply-To: <20260303-rust-pci-sriov-v3-10-4443c35f0c88@redhat.com> References: <20260303-rust-pci-sriov-v3-0-4443c35f0c88@redhat.com> <20260303-rust-pci-sriov-v3-10-4443c35f0c88@redhat.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Patch Review Good sample that exercises the full API: `enable_sriov`, `disable_sriov`, `= physfn`, `drvdata`, `is_virtfn`, `is_physfn`, `num_vf`. ```rust +use core::any::TypeId; ``` Using `TypeId` as dummy private data is a clever way to demonstrate the `dr= vdata` access without needing actual meaningful state. The `assert!()` calls (e.g., `assert!(physfn.is_physfn())`, `assert_eq!(pde= v.num_vf(), nr_virtfn)`) will panic in the kernel if they fail. For a sampl= e this is fine to clearly demonstrate invariants, but it's worth noting the= se would be inappropriate in a production driver. The sample correctly does **not** call `disable_sriov()` in its `PinnedDrop= ` =E2=80=94 the `managed_sriov` mechanism handles this via `pci_iov_disable= ()` before the driver's remove callback runs. --- Generated by Claude Code Patch Reviewer