Re: [PATCH v2] io_uring: add support for probing opcodes

[Jeff Moyer <jmoyer@redhat.com>]

Mark Papadakis <markuspapadakis@icloud.com> writes:

> I 've been thinking about this earlier.
> I think the most realistic solution would be to have kind of
> website/page(libiouring.org?), which lists all SQE OPs, the kernel
> release that first implemented support for it, and (if necessary)
> notes about compatibility.
>
> - There will be, hopefully, a lot more such OPS implemented in the future
> - By having this list readily available, one can determine the lowest
> Linux Kernel release required(target) for a specific set of OPs they
> need for their program. If I want support for readv, writev, accept,
> and connect - say - then I should be able to quickly figure out that
> e.g 5.5 is the minimum LK release I must require

This falls apart when you start looking at distro kernels.  RHEL and
SuSe routinely backport features and fixes, and there may be subsets of
functionality available.  Feature testing really is the best way.

> - Subtle issues may be discovered, or other such important specifics
> may be to be called out -- e.g readv works for < 5.5 for disk I/O but
> (e.g) "broken" for 5.4.3. This should be included in that table

That's true.  I had wondered whether you should be able to specify an
fd, to see if an operation was supported for that particular thing
(file, socket, whatever).  However, I'm not sure how easy that would be
to implement.

One other thing that might be useful is to ask about a specific op.
The way this is implemented, you have to get an entire table, and then
look up the op in that table.  I don't think it's a big deal, though.

> Testing against specific SQE OPs support alone won't be enough, and it
> will likely also get convoluted fast.  liburing could provide a simple
> utility function that returns the (major, minor) LK release for
> convenience.

Again, that model doesn't work for all kernels.

Cheers,
Jeff