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

[Jens Axboe <axboe@kernel.dk>]

On 1/17/20 12:42 AM, Mark Papadakis wrote:
> 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 - 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

The problem with this approach is that io_uring is (mostly) a one man
show so far, and maintaining a web page is not part of my core skill
set, nor is it something I want to take on. It'd be awesome if someone
else would step up on that front. Might be easier to simply keep the
liburing man pages up-to-date and maintain the information in there.

I think a lot of the issues you mention above are early teething issues,
hopefully won't be much of a concern going forward as things solidy and
stabilize on all fronts. So we're left with mostly "is this supported in
the kernel I'm on" kind of questions, which would hopefully be request
specific.

One thing that has been brought up is that we could add an opcode
version. There's an u8 reserved field next to the opcode, that could be
turned into

	__u8 version;

in the future, which would allow us to differentiate types of supported
for an individual opcode. Your readv example would work with that, for
instance.

> 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.

I'm not a huge fan of versioning, exactly because it requires some other
source of information to then cross check a version number with
features. Then the application needs to maintain it to. It also totally
breaks down for backports, where you may only selectively backport
features to an older kernel. You can't represent that with a major.minor
that is sytem wide. The table can.

-- 
Jens Axboe