Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: - [Medium] Incomplete API Implementation: PCI FFI boundary methods continue to return raw `bindings::resource_size_t` instead of the typed `ResourceSize` API. - [Low] Incorrect import order for `core::num::TryFromIntError` violating kernel guidelines. --
--- Patch [1]: [PATCH v2] rust: io: convert ResourceSize into a transparent newtype --- commit b81b66fe76cbe9487443105d289e399a714dd21d Author: Lorenzo Delgado <[email protected]> rust: io: convert ResourceSize into a transparent newtype This patch wraps ResourceSize in a #[repr(transparent)] newtype to prevent unintended integer operations and truncating casts. It provides explicit boundary conversions and updates existing producers and consumers to use the new typed API. Link: https://github.com/Rust-for-Linux/linux/issues/1203 > Wrap it in a `#[repr(transparent)]` newtype so each conversion at a > boundary becomes explicit and reviewable. The representation is > unchanged, so this is ABI-identical; only the spelling at the FFI > boundary changes. Provide the conversion surface `from_raw`/`into_raw`, > `From` in both directions, and a fallible `TryFrom<ResourceSize> for > usize` for checked narrowing. Update the two producers, `Resource::size` > and `SGEntry::dma_len`, and the `request_region` consumer. In nova-core, [Severity: Medium] Does this miss other producers in the FFI boundary? Looking at rust/kernel/pci.rs, both resource_start() and resource_len() continue to return the raw bindings::resource_size_t type rather than the new ResourceSize type. Should these functions also be updated to return the new ResourceSize type to ensure the API remains consistent and fully protected against implicit casts across the subsystem? > diff --git a/rust/kernel/io.rs b/rust/kernel/io.rs > index fcc7678fd9e3c..ebf00b4536d6d 100644 > --- a/rust/kernel/io.rs > +++ b/rust/kernel/io.rs > @@ -6,9 +6,12 @@ > > use crate::{ > bindings, > + fmt, > prelude::*, // > }; > > +use core::num::TryFromIntError; [Severity: Low] This isn't a bug, but should the core import be placed before the crate imports? The kernel's Rust coding guidelines typically require vertical imports where core and alloc are grouped together and placed before kernel (or crate) imports. -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
