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
