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

[Sidong Yang]

On Sat, Apr 11, 2026 at 02:27:14PM +0200, Greg Kroah-Hartman wrote:
> 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 for the clarification.

I will proceed with this uring_cmd Rust abstraction patch as is. Moving 
forward with our AI accelerator driver, I will look into implementing it 
using the accel subsystem and work on creating the necessary Rust 
abstractions for it.

Since I am planning to adopt the accel subsystem, could you share some 
insights on the main benefits it provides for AI accelerators, or point me 
to any future roadmap/plans for the subsystem? This would be very helpful 
for my design and implementation.

Thanks,
Sidong

> 
> thanks,
> 
> greg k-h