Re: Detecting RWF_NOWAIT support

From: Avi Kivity
Date: Mon Dec 18 2017 - 02:38:53 EST

On 12/18/2017 05:28 AM, Goldwyn Rodrigues wrote:

On 12/16/2017 08:49 AM, Avi Kivity wrote:

On 12/14/2017 09:15 PM, Goldwyn Rodrigues wrote:
On 12/14/2017 11:38 AM, Avi Kivity wrote:
I'm looking to add support for RWF_NOWAIT within a linux-aio iocb.
Naturally, I need to detect at runtime whether the kernel support
RWF_NOWAIT or not.

The only method I could find was to issue an I/O with RWF_NOWAIT set,
and look for errors. This is somewhat less than perfect:

ÂÂ- from the error, I can't tell whether RWF_NOWAIT was the problem, or
something else. If I enable a number of new features, I have to run
through all combinations to figure out which ones are supported and
which are not.
Here is the return codes for RWF_NOWAIT
EINVAL - not supported (older kernel)
EOPNOTSUPP - not supported
EAGAIN - supported but could not complete because I/O will be delayed
Which of these are returned from io_submit() and which are returned in
the iocb?
These are returned in iocb.


0 - supported and I/O completed (success).

ÂÂ- RWF_NOWAIT support is per-filesystem, so I can't just remember
not to
enable RWF_NOWAIT globally, I have to track it per file.
Yes, the support is per filesystem. So, the application must know if the
filesystem supports it, possibly by performing a small I/O.
So the application must know about filesystem mount points, and be
prepared to create a file and try to write it (in case the filesystem is
empty) or alter its behavior during runtime depending on the errors it
Well yes. Hopefully, the application knows what it is doing when it
performs RWF_NOWAIT.

This type of interface makes it very hard to consume new kernel facilities in a backward compatible way. The kernel should advertise what support it provides; for example this support could be advertised via statx(2).

For examples of facilities that advertise their capabilities, see membarrier(2) and KVM.