Message-ID: <b38b118f-9bcb-c2fc-4365-0b94fde4e1ec@kernel.org>
Date:   Fri, 4 Oct 2019 17:15:59 -0600
From:   shuah <shuah@...nel.org>
To:     Brendan Higgins <brendanhiggins@...gle.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        "Theodore Y. Ts'o" <tytso@....edu>,
        Frank Rowand <frowand.list@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Kees Cook <keescook@...gle.com>,
        Kieran Bingham <kieran.bingham@...asonboard.com>,
        Luis Chamberlain <mcgrof@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Rob Herring <robh@...nel.org>, Stephen Boyd <sboyd@...nel.org>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        devicetree <devicetree@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        kunit-dev@...glegroups.com,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>,
        linux-nvdimm <linux-nvdimm@...ts.01.org>,
        linux-um@...ts.infradead.org,
        Sasha Levin <Alexander.Levin@...rosoft.com>,
        "Bird, Timothy" <Tim.Bird@...y.com>,
        Amir Goldstein <amir73il@...il.com>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        Daniel Vetter <daniel@...ll.ch>, Jeff Dike <jdike@...toit.com>,
        Joel Stanley <joel@....id.au>,
        Julia Lawall <julia.lawall@...6.fr>,
        Kevin Hilman <khilman@...libre.com>,
        Knut Omang <knut.omang@...cle.com>,
        Logan Gunthorpe <logang@...tatee.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        shuah <shuah@...nel.org>, Randy Dunlap <rdunlap@...radead.org>,
        Richard Weinberger <richard@....at>,
        David Rientjes <rientjes@...gle.com>,
        Steven Rostedt <rostedt@...dmis.org>, wfg@...ux.intel.com
Subject: Re: [PATCH v18 00/19] kunit: introduce KUnit, the Linux kernel unit
 testing framework

On 10/4/19 5:10 PM, Brendan Higgins wrote:
> On Fri, Oct 4, 2019 at 3:47 PM shuah <shuah@...nel.org> wrote:
>>
>> On 10/4/19 4:27 PM, Brendan Higgins wrote:
>>> On Fri, Oct 04, 2019 at 03:59:10PM -0600, shuah wrote:
>>>> On 10/4/19 3:42 PM, Linus Torvalds wrote:
>>>>> On Fri, Oct 4, 2019 at 2:39 PM Theodore Y. Ts'o <tytso@....edu> wrote:
>>>>>>
>>>>>> This question is primarily directed at Shuah and Linus....
>>>>>>
>>>>>> What's the current status of the kunit series now that Brendan has
>>>>>> moved it out of the top-level kunit directory as Linus has requested?
>>>>>
>>>>
>>>> The move happened smack in the middle of merge window and landed in
>>>> linux-next towards the end of the merge window.
>>>>
>>>>> We seemed to decide to just wait for 5.5, but there is nothing that
>>>>> looks to block that. And I encouraged Shuah to find more kunit cases
>>>>> for when it _does_ get merged.
>>>>>
>>>>
>>>> Right. I communicated that to Brendan that we could work on adding more
>>>> kunit based tests which would help get more mileage on the kunit.
>>>>
>>>>> So if the kunit branch is stable, and people want to start using it
>>>>> for their unit tests, then I think that would be a good idea, and then
>>>>> during the 5.5 merge window we'll not just get the infrastructure,
>>>>> we'll get a few more users too and not just examples.
>>>
>>> I was planning on holding off on accepting more tests/changes until
>>> KUnit is in torvalds/master. As much as I would like to go around
>>> promoting it, I don't really want to promote too much complexity in a
>>> non-upstream branch before getting it upstream because I don't want to
>>> risk adding something that might cause it to get rejected again.
>>>
>>> To be clear, I can understand from your perspective why getting more
>>> tests/usage before accepting it is a good thing. The more people that
>>> play around with it, the more likely that someone will find an issue
>>> with it, and more likely that what is accepted into torvalds/master is
>>> of high quality.
>>>
>>> However, if I encourage arbitrary tests/improvements into my KUnit
>>> branch, it further diverges away from torvalds/master, and is more
>>> likely that there will be a merge conflict or issue that is not related
>>> to the core KUnit changes that will cause the whole thing to be
>>> rejected again in v5.5.
>>>
>>
>> The idea is that the new development will happen based on kunit in
>> linux-kselftest next. It will work just fine. As we accepts patches,
>> they will go on top of kunit that is in linux-next now.
> 
> But then wouldn't we want to limit what KUnit changes are going into
> linux-kselftest next for v5.5? For example, we probably don't want to
> do anymore feature development on it until it is in v5.5, since the
> goal is to make it more stable, right?
> 
> I am guessing that it will probably be fine, but it still sounds like
> we need to establish some ground rules, and play it *very* safe.
> 

How about we identify a small number tests that can add value and focus
on them. I am thinking a number between 2 and 5. This way we get a feel
for the API, if it changes for the better great, if it doesn't have to,
then you know you already did a great job.

Does that sound reasonable to you?

thanks,
-- Shuah

Powered by blists - more mailing lists