[PATCHSET RFC 0/5] file_operations based io_uring commands

[Jens Axboe <axboe@kernel.dk>]

Hi,

This is a concept I've been toying with, some (including myself) have
referred to it as a way to do ioctls over io_uring. And indeed it has
many similarities with that. The purpose of the patchset is to have
a file private command type. io_uring doesn't know or care what is in
it, only the end target would be able to do that. In that sense it's
similar to ioctls which share the same trait. io_uring just provides
all the infrastructure to pass them back and forth, etc.

At the core of it, we overlay a struct type on top of io_uring_sqe.
That's basically like other commands, except this one is a bit more
brutal. That leaves us with 32 bytes that we can use, 8 bytes that
we can't (as they overlap with ->user_data), and then 8 bytes that are
usable again. Hence there's 40 bytes available for a command, anything
more than that should be allocated as per usual for request types.

The file_operations structure is augmented to add a ->uring_cmd()
handler. A file type must support this operation to support these
kinds of commands, otherwise they get errored. This handler can
either queue this operation async and signal completion when done,
or it can complete it inline (either successfully, or in error).

Proof of concept added for raw block and network commands, just to
show how it could work. Nothing exciting/interesting yet, just a
way to test it out.

This is very much sent out for comments/review of the concept itself.
There are a host of things that could be implemented with this, like
raw device access, new APIs (network zero copy additions), etc.

I'm not a huge fan of the command overlay, but I do like the fact that
we can do alloc less commands as long as we stay at <= 40 bytes. So
maybe it's just a pill that we have to swallow. Or maybe there are
other great ideas for how to do this. It does mean that we overlay
much of the sqe, but most of that won't make sense for private commands.

Anyways, comments welcome. This is kept on io_uring for now until
details have been hashed out.

-- 
Jens Axboe