Re: [PATCH v4 0/5] Rust io_uring command abstraction for miscdevice

[Greg Kroah-Hartman]

On Sat, Apr 11, 2026 at 12:16:39PM +0000, Sidong Yang wrote:
> On Thu, Apr 09, 2026 at 07:25:23AM +0200, Greg Kroah-Hartman wrote:
> > On Wed, Apr 08, 2026 at 01:59:57PM +0000, Sidong Yang wrote:
> > > This series introduces Rust abstractions for io_uring commands
> > > (`IORING_OP_URING_CMD`) and wires them up to the miscdevice framework,
> > > allowing Rust drivers to handle io_uring passthrough commands.
> > > 
> > > The series is structured as follows:
> > > 
> > > 1. Add io_uring C headers to Rust bindings.
> > > 2. Zero-init pdu in io_uring_cmd_prep() to avoid UB from stale data.
> > > 3. Core io_uring Rust abstractions (IoUringCmd, QueuedIoUringCmd,
> > >    IoUringSqe, UringCmdAction type-state pattern).
> > > 4. MiscDevice trait extension with uring_cmd callback.
> > > 5. Sample demonstrating async uring_cmd handling via workqueue.
> > > 
> > > The sample completes asynchronously using a workqueue rather than
> > > `io_uring_cmd_complete_in_task()`.  The latter is primarily needed
> > > when completion originates from IRQ/softirq context (e.g. NVMe),
> > > whereas workqueue workers already run in process context and can
> > > safely call `io_uring_cmd_done()` directly.  A Rust binding for
> > > `complete_in_task` can be added in a follow-up series.
> > > 
> > > Copy-based `read_pdu()`/`write_pdu()` are kept instead of returning
> > > `&T`/`&mut T` references because the PDU is a `[u8; 32]` byte array
> > > whose alignment may not satisfy `T`'s requirements.
> > 
> > Samples are great and all, but I would really like to see a real user of
> > this before adding any more miscdev apis to the kernel.  Can you submit
> > this as a series that also adds the driver that needs this at the same
> > time?
> 
> Hi Greg,
> 
> Thank you for the review.
> 
> We have an out-of-tree C driver at Furiosa AI for our AI inference
> accelerator that uses uring_cmd.  This is our primary motivation for
> these abstractions.
> 
> We are considering upstreaming the driver and porting parts of it to
> Rust using these abstractions.  If we were to upstream the driver,
> would it need to be based on the accel subsystem (DRM)?  Or would a
> standalone PCI driver approach also be acceptable?

Yes, it must use the accel subsystem as that is the correct api for it.

thanks,

greg k-h