[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210917084309.rmlly66jpikx7h4q@wittgenstein>
Date: Fri, 17 Sep 2021 10:43:09 +0200
From: Christian Brauner <christian.brauner@...ntu.com>
To: Christoph Hellwig <hch@...radead.org>
Cc: Mike Christie <michael.christie@...cle.com>, stefanha@...hat.com,
jasowang@...hat.com, mst@...hat.com, sgarzare@...hat.com,
virtualization@...ts.linux-foundation.org, axboe@...nel.dk,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/8] fork: add helper to clone a process
On Fri, Sep 17, 2021 at 09:01:06AM +0100, Christoph Hellwig wrote:
> On Fri, Sep 17, 2021 at 09:44:40AM +0200, Christian Brauner wrote:
> > > generally want a printf-like varargs caling conventions. I'd also
> > > much prefer to hide as much as possible in the actual helper. That is
> > > build a helper that gets the name, a flag to ignore the singals etc
> > > instead of exporting all these random low-level helpers.
> >
> > Yes, I think that's really what we want here.
>
> In a way this would mean enhancing the kthread API to also support I/O
> threads.
Kinda, it's a kthread in so far as it has been created by the kernel and
not through a regular syscall path. But it's not really using any of the
kthread.c stuff.
I think the general push of the series is right. We should aim for a
helper that allows a driver - similar to what uring already does - to
create a task with the context of the caller.
After the fork/clone rework that I did it shouldn't be that difficult to
do. The uring patch did show that it's fairly straightforward.
Powered by blists - more mailing lists