[PATCH v2 liburing] add helper functions to verify io_uring functionality

[PATCH v2 liburing] add helper functions to verify io_uring functionality

[Glauber Costa]

It is common for an application using an ever-evolving interface to want
to inquire about the presence of certain functionality it plans to use.

Information about opcodes is stored in a io_uring_probe structure. There
is usually some boilerplate involved in initializing one, and then using
it to check if it is enabled.

This patch adds two new helper functions: one that returns a pointer to
a io_uring_probe (or null if it probe is not available), and another one
that given a probe checks if the opcode is supported.

Signed-off-by: Glauber Costa <glauber@scylladb.com>
CC: Avi Kivity <avi@scylladb.com>
---
 src/include/liburing.h | 11 +++++++++++
 src/liburing.map       |  1 +
 src/setup.c            | 19 +++++++++++++++++++
 3 files changed, 31 insertions(+)

diff --git a/src/include/liburing.h b/src/include/liburing.h
index 83d11dd..da52ca6 100644
--- a/src/include/liburing.h
+++ b/src/include/liburing.h
@@ -72,6 +72,17 @@ struct io_uring {
 /*
  * Library interface
  */
+
+/*
+ * return an allocated io_uring_probe structure, or NULL if probe fails (for
+ * example, if it is not available). The caller is responsible for freeing it
+ */
+extern struct io_uring_probe *io_uring_get_probe(struct io_uring *ring);
+
+static inline int io_uring_opcode_supported(struct io_uring_probe *p, int op) {
+	return (p->last_op > op) && (p->ops[op].flags & IO_URING_OP_SUPPORTED);
+}
+
 extern int io_uring_queue_init_params(unsigned entries, struct io_uring *ring,
 	struct io_uring_params *p);
 extern int io_uring_queue_init(unsigned entries, struct io_uring *ring,
diff --git a/src/liburing.map b/src/liburing.map
index b45f373..ac8288a 100644
--- a/src/liburing.map
+++ b/src/liburing.map
@@ -72,4 +72,5 @@ LIBURING_0.4 {
 		io_uring_register_probe;
 		io_uring_register_personality;
 		io_uring_unregister_personality;
+		io_uring_get_probe;
 } LIBURING_0.3;
diff --git a/src/setup.c b/src/setup.c
index c53f234..c03274c 100644
--- a/src/setup.c
+++ b/src/setup.c
@@ -4,6 +4,7 @@
 #include <unistd.h>
 #include <errno.h>
 #include <string.h>
+#include <stdlib.h>
 
 #include "liburing/compat.h"
 #include "liburing/io_uring.h"
@@ -167,3 +168,21 @@ void io_uring_queue_exit(struct io_uring *ring)
 	io_uring_unmap_rings(sq, cq);
 	close(ring->ring_fd);
 }
+
+struct io_uring_probe *io_uring_get_probe(struct io_uring *ring)
+{
+	struct io_uring_probe *probe;
+	int r;
+
+	size_t len = sizeof(*probe) + 256 * sizeof(struct io_uring_probe_op);
+	probe = malloc(len);
+	memset(probe, 0, len);
+	r = io_uring_register_probe(ring, probe, 256);
+	if (r < 0)
+		goto fail;
+
+	return probe;
+fail:
+	free(probe);
+	return NULL;
+}
-- 
2.20.1

Re: [PATCH v2 liburing] add helper functions to verify io_uring functionality

[Jens Axboe]

On 1/30/20 9:00 AM, Glauber Costa wrote:
> It is common for an application using an ever-evolving interface to want
> to inquire about the presence of certain functionality it plans to use.
> 
> Information about opcodes is stored in a io_uring_probe structure. There
> is usually some boilerplate involved in initializing one, and then using
> it to check if it is enabled.
> 
> This patch adds two new helper functions: one that returns a pointer to
> a io_uring_probe (or null if it probe is not available), and another one
> that given a probe checks if the opcode is supported.

This looks good, I committed it with minor changes.

On top of this, we should have a helper that doesn't need a ring. So
basically one that just sets up a ring, calls io_uring_get_probe(),
then tears down the ring.

-- 
Jens Axboe

Re: [PATCH v2 liburing] add helper functions to verify io_uring functionality

[Glauber Costa]

On Thu, Jan 30, 2020 at 11:13 AM Jens Axboe <axboe@kernel.dk> wrote:
>
> On 1/30/20 9:00 AM, Glauber Costa wrote:
> > It is common for an application using an ever-evolving interface to want
> > to inquire about the presence of certain functionality it plans to use.
> >
> > Information about opcodes is stored in a io_uring_probe structure. There
> > is usually some boilerplate involved in initializing one, and then using
> > it to check if it is enabled.
> >
> > This patch adds two new helper functions: one that returns a pointer to
> > a io_uring_probe (or null if it probe is not available), and another one
> > that given a probe checks if the opcode is supported.
>
> This looks good, I committed it with minor changes.
>
> On top of this, we should have a helper that doesn't need a ring. So
> basically one that just sets up a ring, calls io_uring_get_probe(),
> then tears down the ring.
>
I'd be happy to follow up with that.

Just to be sure, the information returned by probe should be able to outlive the
tear down of the ring, right ?

Re: [PATCH v2 liburing] add helper functions to verify io_uring functionality

[Jens Axboe]

On 1/30/20 9:29 AM, Glauber Costa wrote:
> On Thu, Jan 30, 2020 at 11:13 AM Jens Axboe <axboe@kernel.dk> wrote:
>>
>> On 1/30/20 9:00 AM, Glauber Costa wrote:
>>> It is common for an application using an ever-evolving interface to want
>>> to inquire about the presence of certain functionality it plans to use.
>>>
>>> Information about opcodes is stored in a io_uring_probe structure. There
>>> is usually some boilerplate involved in initializing one, and then using
>>> it to check if it is enabled.
>>>
>>> This patch adds two new helper functions: one that returns a pointer to
>>> a io_uring_probe (or null if it probe is not available), and another one
>>> that given a probe checks if the opcode is supported.
>>
>> This looks good, I committed it with minor changes.
>>
>> On top of this, we should have a helper that doesn't need a ring. So
>> basically one that just sets up a ring, calls io_uring_get_probe(),
>> then tears down the ring.
>>
> I'd be happy to follow up with that.
> 
> Just to be sure, the information returned by probe should be able to outlive the
> tear down of the ring, right ?

Yeah, same lifetime as the helper you have now, caller must free it once
done.

-- 
Jens Axboe

Re: [PATCH v2 liburing] add helper functions to verify io_uring functionality

[Glauber Costa]

On Thu, Jan 30, 2020 at 11:31 AM Jens Axboe <axboe@kernel.dk> wrote:
>
> On 1/30/20 9:29 AM, Glauber Costa wrote:
> > On Thu, Jan 30, 2020 at 11:13 AM Jens Axboe <axboe@kernel.dk> wrote:
> >>
> >> On 1/30/20 9:00 AM, Glauber Costa wrote:
> >>> It is common for an application using an ever-evolving interface to want
> >>> to inquire about the presence of certain functionality it plans to use.
> >>>
> >>> Information about opcodes is stored in a io_uring_probe structure. There
> >>> is usually some boilerplate involved in initializing one, and then using
> >>> it to check if it is enabled.
> >>>
> >>> This patch adds two new helper functions: one that returns a pointer to
> >>> a io_uring_probe (or null if it probe is not available), and another one
> >>> that given a probe checks if the opcode is supported.
> >>
> >> This looks good, I committed it with minor changes.
> >>
> >> On top of this, we should have a helper that doesn't need a ring. So
> >> basically one that just sets up a ring, calls io_uring_get_probe(),
> >> then tears down the ring.
> >>
> > I'd be happy to follow up with that.
> >
> > Just to be sure, the information returned by probe should be able to outlive the
> > tear down of the ring, right ?
>
> Yeah, same lifetime as the helper you have now, caller must free it once
> done.

Well, in hindsight, I should have called that
io_uring_get_probe_ring() so io_uring_get_probe()
doesn't take a ring.

Alternatively, to keep things in a single function, I can change
io_uring_get_probe() so that if it
ring is NULL, we do our own allocation.

I actually kind of like that. Would that work for you ?

>
> --
> Jens Axboe
>

Re: [PATCH v2 liburing] add helper functions to verify io_uring functionality

[Jens Axboe]

On 1/31/20 6:52 AM, Glauber Costa wrote:
> On Thu, Jan 30, 2020 at 11:31 AM Jens Axboe <axboe@kernel.dk> wrote:
>>
>> On 1/30/20 9:29 AM, Glauber Costa wrote:
>>> On Thu, Jan 30, 2020 at 11:13 AM Jens Axboe <axboe@kernel.dk> wrote:
>>>>
>>>> On 1/30/20 9:00 AM, Glauber Costa wrote:
>>>>> It is common for an application using an ever-evolving interface to want
>>>>> to inquire about the presence of certain functionality it plans to use.
>>>>>
>>>>> Information about opcodes is stored in a io_uring_probe structure. There
>>>>> is usually some boilerplate involved in initializing one, and then using
>>>>> it to check if it is enabled.
>>>>>
>>>>> This patch adds two new helper functions: one that returns a pointer to
>>>>> a io_uring_probe (or null if it probe is not available), and another one
>>>>> that given a probe checks if the opcode is supported.
>>>>
>>>> This looks good, I committed it with minor changes.
>>>>
>>>> On top of this, we should have a helper that doesn't need a ring. So
>>>> basically one that just sets up a ring, calls io_uring_get_probe(),
>>>> then tears down the ring.
>>>>
>>> I'd be happy to follow up with that.
>>>
>>> Just to be sure, the information returned by probe should be able to outlive the
>>> tear down of the ring, right ?
>>
>> Yeah, same lifetime as the helper you have now, caller must free it once
>> done.
> 
> Well, in hindsight, I should have called that
> io_uring_get_probe_ring() so io_uring_get_probe()
> doesn't take a ring.

Just change it - we just added it yesterday, and it's not released yet.
I don't break anything that's been in a release, and I maintain
compatibility between releases, but we can change it now.

> Alternatively, to keep things in a single function, I can change
> io_uring_get_probe() so that if it
> ring is NULL, we do our own allocation.
> 
> I actually kind of like that. Would that work for you ?

Not a huge deal to me, we can go that route.

-- 
Jens Axboe

Re: [PATCH v2 liburing] add helper functions to verify io_uring functionality

[Glauber Costa]

On Fri, Jan 31, 2020 at 10:14 AM Jens Axboe <axboe@kernel.dk> wrote:
>
> On 1/31/20 6:52 AM, Glauber Costa wrote:
> > On Thu, Jan 30, 2020 at 11:31 AM Jens Axboe <axboe@kernel.dk> wrote:
> >>
> >> On 1/30/20 9:29 AM, Glauber Costa wrote:
> >>> On Thu, Jan 30, 2020 at 11:13 AM Jens Axboe <axboe@kernel.dk> wrote:
> >>>>
> >>>> On 1/30/20 9:00 AM, Glauber Costa wrote:
> >>>>> It is common for an application using an ever-evolving interface to want
> >>>>> to inquire about the presence of certain functionality it plans to use.
> >>>>>
> >>>>> Information about opcodes is stored in a io_uring_probe structure. There
> >>>>> is usually some boilerplate involved in initializing one, and then using
> >>>>> it to check if it is enabled.
> >>>>>
> >>>>> This patch adds two new helper functions: one that returns a pointer to
> >>>>> a io_uring_probe (or null if it probe is not available), and another one
> >>>>> that given a probe checks if the opcode is supported.
> >>>>
> >>>> This looks good, I committed it with minor changes.
> >>>>
> >>>> On top of this, we should have a helper that doesn't need a ring. So
> >>>> basically one that just sets up a ring, calls io_uring_get_probe(),
> >>>> then tears down the ring.
> >>>>
> >>> I'd be happy to follow up with that.
> >>>
> >>> Just to be sure, the information returned by probe should be able to outlive the
> >>> tear down of the ring, right ?
> >>
> >> Yeah, same lifetime as the helper you have now, caller must free it once
> >> done.
> >
> > Well, in hindsight, I should have called that
> > io_uring_get_probe_ring() so io_uring_get_probe()
> > doesn't take a ring.
>
> Just change it - we just added it yesterday, and it's not released yet.
> I don't break anything that's been in a release, and I maintain
> compatibility between releases, but we can change it now.

Yeah, I figured as much and ended up changing it.

>
> > Alternatively, to keep things in a single function, I can change
> > io_uring_get_probe() so that if it
> > ring is NULL, we do our own allocation.
> >
> > I actually kind of like that. Would that work for you ?
>
> Not a huge deal to me, we can go that route.
>
> --
> Jens Axboe
>