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
