On Fri, Jul 11, 2025 at 10:46:13PM +0200, Benno Lossin wrote: > On Fri Jul 11, 2025 at 9:33 PM CEST, Danilo Krummrich wrote: > > On Fri Jul 11, 2025 at 8:30 PM CEST, Benno Lossin wrote: > >> On Fri Jul 11, 2025 at 5:02 PM CEST, Danilo Krummrich wrote: > >>> On Thu Jul 10, 2025 at 10:01 AM CEST, Benno Lossin wrote: > >>>> On Thu Jul 10, 2025 at 4:24 AM CEST, Alistair Popple wrote: > >>>>> diff --git a/rust/kernel/pci.rs b/rust/kernel/pci.rs > >>>>> index 8435f8132e38..5c35a66a5251 100644 > >>>>> --- a/rust/kernel/pci.rs > >>>>> +++ b/rust/kernel/pci.rs > >>>>> @@ -371,14 +371,18 @@ fn as_raw(&self) -> *mut bindings::pci_dev { > >>>>> > >>>>> impl Device { > >>>>> /// Returns the PCI vendor ID. > >>>>> + #[inline] > >>>>> pub fn vendor_id(&self) -> u16 { > >>>>> - // SAFETY: `self.as_raw` is a valid pointer to a `struct pci_dev`. > >>>>> + // SAFETY: by its type invariant `self.as_raw` is always a valid pointer to a > >>>> > >>>> s/by its type invariant/by the type invariants of `Self`,/ > >>>> s/always// > >>>> > >>>> Also, which invariant does this refer to? The only one that I can see > >>>> is: > >>>> > >>>> /// A [`Device`] instance represents a valid `struct device` created by the C portion of the kernel. > >>>> > >>>> And this doesn't say anything about the validity of `self.as_raw()`... > >>> > >>> Hm...why not? If an instance of Self always represents a valid struct pci_dev, > >>> then consequently self.as_raw() can only be a valid pointer to a struct pci_dev, > >>> no? > >> > >> While it's true, you need to look into the implementation of `as_raw`. > >> It could very well return a null pointer... > >> > >> This is where we can use a `Guarantee` on that function. But since it's > >> not shorter than `.0.get()`, I would just remove it. > > > > We have 15 to 20 as_raw() methods of this kind in the tree. If this really needs > > a `Guarantee` to be clean, we should probably fix it up in a treewide change. > > > > as_raw() is a common pattern and everyone knows what it does, `.0.get()` seems > > much less obvious. Coming from a C kernel programming background I agree `.as_raw()` is more obvious than `.0.get()`. However now I'm confused ... what if anything needs changing to get these two small patches merged? Thanks. - Alistair > Yeah I guess then we need to do the treewide change... I don't have the > bandwidth for that, we can probably make this a good-first-issue. > > --- > Cheers, > Benno