* [PATCH v2 liburing] add helper functions to verify io_uring functionality
@ 2020-01-30 16:00 Glauber Costa
2020-01-30 16:13 ` Jens Axboe
0 siblings, 1 reply; 7+ messages in thread
From: Glauber Costa @ 2020-01-30 16:00 UTC (permalink / raw)
To: io-uring; +Cc: axboe, Glauber Costa, Avi Kivity
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 <[email protected]>
CC: Avi Kivity <[email protected]>
---
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
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH v2 liburing] add helper functions to verify io_uring functionality
2020-01-30 16:00 [PATCH v2 liburing] add helper functions to verify io_uring functionality Glauber Costa
@ 2020-01-30 16:13 ` Jens Axboe
2020-01-30 16:29 ` Glauber Costa
0 siblings, 1 reply; 7+ messages in thread
From: Jens Axboe @ 2020-01-30 16:13 UTC (permalink / raw)
To: Glauber Costa, io-uring; +Cc: Avi Kivity
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2 liburing] add helper functions to verify io_uring functionality
2020-01-30 16:13 ` Jens Axboe
@ 2020-01-30 16:29 ` Glauber Costa
2020-01-30 16:31 ` Jens Axboe
0 siblings, 1 reply; 7+ messages in thread
From: Glauber Costa @ 2020-01-30 16:29 UTC (permalink / raw)
To: Jens Axboe; +Cc: io-uring, Avi Kivity
On Thu, Jan 30, 2020 at 11:13 AM Jens Axboe <[email protected]> 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 ?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2 liburing] add helper functions to verify io_uring functionality
2020-01-30 16:29 ` Glauber Costa
@ 2020-01-30 16:31 ` Jens Axboe
2020-01-31 13:52 ` Glauber Costa
0 siblings, 1 reply; 7+ messages in thread
From: Jens Axboe @ 2020-01-30 16:31 UTC (permalink / raw)
To: Glauber Costa; +Cc: io-uring, Avi Kivity
On 1/30/20 9:29 AM, Glauber Costa wrote:
> On Thu, Jan 30, 2020 at 11:13 AM Jens Axboe <[email protected]> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2 liburing] add helper functions to verify io_uring functionality
2020-01-30 16:31 ` Jens Axboe
@ 2020-01-31 13:52 ` Glauber Costa
2020-01-31 15:14 ` Jens Axboe
0 siblings, 1 reply; 7+ messages in thread
From: Glauber Costa @ 2020-01-31 13:52 UTC (permalink / raw)
To: Jens Axboe; +Cc: io-uring, Avi Kivity
On Thu, Jan 30, 2020 at 11:31 AM Jens Axboe <[email protected]> wrote:
>
> On 1/30/20 9:29 AM, Glauber Costa wrote:
> > On Thu, Jan 30, 2020 at 11:13 AM Jens Axboe <[email protected]> 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
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2 liburing] add helper functions to verify io_uring functionality
2020-01-31 13:52 ` Glauber Costa
@ 2020-01-31 15:14 ` Jens Axboe
2020-01-31 15:27 ` Glauber Costa
0 siblings, 1 reply; 7+ messages in thread
From: Jens Axboe @ 2020-01-31 15:14 UTC (permalink / raw)
To: Glauber Costa; +Cc: io-uring, Avi Kivity
On 1/31/20 6:52 AM, Glauber Costa wrote:
> On Thu, Jan 30, 2020 at 11:31 AM Jens Axboe <[email protected]> wrote:
>>
>> On 1/30/20 9:29 AM, Glauber Costa wrote:
>>> On Thu, Jan 30, 2020 at 11:13 AM Jens Axboe <[email protected]> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2 liburing] add helper functions to verify io_uring functionality
2020-01-31 15:14 ` Jens Axboe
@ 2020-01-31 15:27 ` Glauber Costa
0 siblings, 0 replies; 7+ messages in thread
From: Glauber Costa @ 2020-01-31 15:27 UTC (permalink / raw)
To: Jens Axboe; +Cc: io-uring, Avi Kivity
On Fri, Jan 31, 2020 at 10:14 AM Jens Axboe <[email protected]> wrote:
>
> On 1/31/20 6:52 AM, Glauber Costa wrote:
> > On Thu, Jan 30, 2020 at 11:31 AM Jens Axboe <[email protected]> wrote:
> >>
> >> On 1/30/20 9:29 AM, Glauber Costa wrote:
> >>> On Thu, Jan 30, 2020 at 11:13 AM Jens Axboe <[email protected]> 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
>
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-01-31 15:27 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-01-30 16:00 [PATCH v2 liburing] add helper functions to verify io_uring functionality Glauber Costa
2020-01-30 16:13 ` Jens Axboe
2020-01-30 16:29 ` Glauber Costa
2020-01-30 16:31 ` Jens Axboe
2020-01-31 13:52 ` Glauber Costa
2020-01-31 15:14 ` Jens Axboe
2020-01-31 15:27 ` Glauber Costa
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox