[PATCH 1/8] io_uring: split up io_uring_sqe into hdr + main

[Christoph Hellwig]

On Thu, Mar 18, 2021 at 12:40:25PM -0600, Jens Axboe wrote:
> > and use that for all new commands going forward while marking the
> > old ones as legacy.
> > 
> > io_uring_cmd_sqe would then be:
> > 
> > struct io_uring_cmd_sqe {
> >         struct io_uring_sqe_hdr	hdr;
> > 	__u33			ioc;
> > 	__u32 			len;
> > 	__u8			data[40];
> > };
> > 
> > for example.  Note the 32-bit opcode just like ioctl to avoid
> > getting into too much trouble due to collisions.
> 
> I was debating that with myself too, it's essentially making
> the existing io_uring_sqe into io_uring_sqe_v1 and then making a new
> v2 one. That would impact _all_ commands, and we'd need some trickery
> to have newly compiled stuff use v2 and have existing applications
> continue to work with the v1 format. That's very different from having
> a single (or new) opcodes use a v2 format, effectively.

I only proposed it for all new commands because we have so many
existing ones.

> Looking into the feasibility of this. But if that is done, there are
> other things that need to be factored in, as I'm not at all interested
> in having a v3 down the line as well. And I'd need to be able to do this
> seamlessly, both from an application point of view, and a performance
> point of view (no stupid conversions inline).
> 
> Things that come up when something like this is on the table
> 
> - Should flags be extended? We're almost out... It hasn't been an
>   issue so far, but seems a bit silly to go v2 and not at least leave
>   a bit of room there. But obviously comes at a cost of losing eg 8
>   bits somewhere else.
> 
> - Is u8 enough for the opcode? Again, we're nowhere near the limits
>   here, but eventually multiplexing might be necessary.
> 
> That's just off the top of my head, probably other things to consider
> too.

At some point there isn't much left of the common space if we
extend all that, but yeah.