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.
