Re: [PATCH v2] rust/kernel: Add faux device bindings

[Danilo Krummrich]

On Fri, Feb 07, 2025 at 10:25:09AM +0100, Greg Kroah-Hartman wrote:
> On Thu, Feb 06, 2025 at 07:40:45PM -0500, Lyude Paul wrote:
> > +
> > +/// The registration of a faux device.
> > +///
> > +/// This type represents the registration of a [`struct faux_device`]. When an instance of this type
> > +/// is dropped, its respective faux device will be unregistered from the system.
> > +///
> > +/// # Invariants
> > +///
> > +/// `self.0` always holds a valid pointer to an initialized and registered [`struct faux_device`].
> > +///
> > +/// [`struct faux_device`]: srctree/include/linux/device/faux.h
> > +#[repr(transparent)]
> > +pub struct Registration(NonNull<bindings::faux_device>);
> > +
> > +impl Registration {
> > +    /// Create and register a new faux device with the given name.
> > +    pub fn new(name: &CStr) -> Result<Self> {
> > +        // SAFETY:
> > +        // - `name` is copied by this function into its own storage
> > +        // - `faux_ops` is safe to leave NULL according to the C API
> > +        let dev = unsafe { bindings::faux_device_create(name.as_char_ptr(), null()) };
> 
> I'm fine with null() here, but why wouldn't a rust binding want to allow
> this?  What's unique here that make it this way, or is it just that the
> current users you are thinking of don't care about it?

This is what I meant when I mentioned allowing NULL for the faux_device_ops
allows us to simplify the Rust abstraction quite a bit.

Having probe() and remove() doesn't do a lot for us in this case in Rust other
than needing a separate faux::Driver trait with a corresponding faux::Adapter
implementation to handle those callbacks. It'd be an unnecessary indirection.

Do you see any advantage going through probe()?