Add unstable io-uring uring_cmd support

[SidongYang]

Summary

Tokio already has unstable io-uring support for OpenAt, Read, and Write in tokio::fs paths. I’d like to propose adding unstable support for IORING_OP_URING_CMD.

Prototype branch: SidongYang:sidong/uring-cmd
Prototype commit: 2d3c8cff

Motivation

Some Linux file/device operations are exposed as uring commands rather than regular read/write syscalls. Supporting IORING_OP_URING_CMD in Tokio’s existing unstable io-uring integration would make those operations available without leaving Tokio’s runtime/driver model.

Proposed API (initial)

A minimal unstable API on tokio::fs::File:

• async fn uring_cmd(&self, cmd_op: u32, cmd: [u8; 16], buf_index: Option<u16>) -> io::Result<u32>

Behavior:

• Same unstable/feature gating as current io-uring support (tokio_unstable, io-uring, rt, fs, Linux).
• Runtime probe via check_and_init(opcode::UringCmd16::CODE).
• Returns ErrorKind::Unsupported if unavailable.

Scope

• Initial support for 16-byte payload (UringCmd16) only.
• Reuses existing op lifecycle + cancellation plumbing.

Open questions

• Is tokio::fs::File the right public API location, or should this be exposed elsewhere (e.g. a lower-level io-uring module)?
• Should Tokio expose a more generic/extensible command payload API up front (or keep initial scope narrow)?

If this direction looks good, I can open/convert a PR with tests and docs aligned to maintainer guidance.

[RajMandaliya]

Thanks for sharing this proposal!

I like that the API keeps things narrow with UringCmd16. One thing I’m curious about is how the cancellation and async runtime integration will be handled for these commands — for example, if a user awaits a long-running uring command and wants to cancel it via tokio::sync primitives, would that fit naturally into the existing op lifecycle?

I’m excited to try this out once the PR with tests is available.