[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230919-beinen-fernab-dbc587acb08d@brauner>
Date: Tue, 19 Sep 2023 16:45:21 +0200
From: Christian Brauner <brauner@...nel.org>
To: Jens Axboe <axboe@...nel.dk>
Cc: io-uring@...r.kernel.org, linux-kernel@...r.kernel.org,
arnd@...db.de, asml.silence@...il.com
Subject: Re: [PATCHSET v4 0/5] Add io_uring support for waitid
On Tue, Sep 12, 2023 at 11:06:39AM -0600, Jens Axboe wrote:
> On 9/9/23 9:11 AM, Jens Axboe wrote:
> > Hi,
> >
> > This adds support for IORING_OP_WAITID, which is an async variant of
> > the waitid(2) syscall. Rather than have a parent need to block waiting
> > on a child task state change, it can now simply get an async notication
> > when the requested state change has occured.
> >
> > Patches 1..4 are purely prep patches, and should not have functional
> > changes. They split out parts of do_wait() into __do_wait(), so that
> > the prepare-to-wait and sleep parts are contained within do_wait().
> >
> > Patch 5 adds io_uring support.
> >
> > I wrote a few basic tests for this, which can be found in the
> > 'waitid' branch of liburing:
> >
> > https://git.kernel.dk/cgit/liburing/log/?h=waitid
> >
> > Also spun a custom kernel for someone to test it, and no issues reported
> > so far.
>
> Forget to mention that I also ran all the ltp testcases for any wait*
> syscall test, and everything still passes just fine.
I think the struct that this ends up exposing to io_uring is pretty ugly
and it would warrant a larger cleanup. I wouldn't be surprised if you
get some people complain about this.
Other than that I don't have any complaints about the series.
Powered by blists - more mailing lists