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

Sidong Yang
2026-04-14T15:36:21Z

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