[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <169449169186.22106.13281613238195902818@noble.neil.brown.name>
Date: Tue, 12 Sep 2023 14:08:11 +1000
From: "NeilBrown" <neilb@...e.de>
To: "Kees Cook" <kees@...nel.org>
Cc: "Chuck Lever" <cel@...nel.org>, linux-nfs@...r.kernel.org,
"Andrew Morton" <akpm@...ux-foundation.org>,
"Liam R. Howlett" <Liam.Howlett@...cle.com>,
"Kees Cook" <keescook@...omium.org>,
"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
"David Gow" <davidgow@...gle.com>, linux-kernel@...r.kernel.org,
"Chuck Lever" <chuck.lever@...cle.com>
Subject: Re: [PATCH v1 11/17] lib: add light-weight queuing mechanism.
On Tue, 12 Sep 2023, Kees Cook wrote:
> On September 11, 2023 7:39:43 AM PDT, Chuck Lever <cel@...nel.org> wrote:
> >From: NeilBrown <neilb@...e.de>
> > [...]
> > Does not use kunit framework.
>
> Any reason why not? It seems like it'd be well suited to it...
A quick look didn't suggest that using Kunit would make my task any
easier. It seemed to require a lot of boiler plate for little gain.
Maybe that was unfair - I didn't spend long looking.
Partly, I put that comment in the commit message so that if one wanted
to try to change my mind - there was a prompt for them to do it.
Also I had a quick look at other test code in lib/ and it all seemed to
use the "run some code at boot time" approach.
So if anyone can make a clear argument why using Kunit will help me, or
will help someone else, I'll consider it. But I cannot see the
motivation without help.
Thanks,
NeilBrown
Powered by blists - more mailing lists