public inbox for [email protected]
 help / color / mirror / Atom feed
From: Mark Papadakis <[email protected]>
To: Jens Axboe <[email protected]>
Cc: io-uring <[email protected]>, Stefan Metzmacher <[email protected]>
Subject: Re: [PATCH v2] io_uring: add support for probing opcodes
Date: Fri, 17 Jan 2020 09:42:50 +0200	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

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

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.

@markpapadakis

  reply	other threads:[~2020-01-17  7:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-17  2:58 [PATCH v2] io_uring: add support for probing opcodes Jens Axboe
2020-01-17  7:42 ` Mark Papadakis [this message]
2020-01-17 15:15   ` Jens Axboe
2020-01-17 17:20   ` Jeff Moyer
2020-01-17 17:15 ` Jeff Moyer
2020-01-17 17:36   ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox