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

[Sidong Yang]

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?

Thanks,
Sidong

> 
> thanks,
> 
> greg k-h