Re: [PATCH] kunit: tool: make --kunitconfig accept dirs, add lib/kunit fragment

From: Shuah Khan <skhan@linuxfoundation.org>
To: Daniel Latypov <dlatypov@google.com>
Cc: Brendan Higgins <brendanhiggins@google.com>,
	David Gow <davidgow@google.com>,
	KUnit Development <kunit-dev@googlegroups.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"open list:KERNEL SELFTEST FRAMEWORK" 
	<linux-kselftest@vger.kernel.org>, Theodore Ts'o <tytso@mit.edu>,
	Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [PATCH] kunit: tool: make --kunitconfig accept dirs, add lib/kunit fragment
Date: Fri, 2 Apr 2021 13:31:17 -0600	[thread overview]
Message-ID: <97706798-cf13-a21f-fdbf-5cecd9f7d6d0@linuxfoundation.org> (raw)
In-Reply-To: <CAGS_qxqoXhZo6hV_1BsqrpXBJTuBhXERUnW75U6aCtS382aNjg@mail.gmail.com>

On 4/2/21 1:27 PM, Daniel Latypov wrote:
> On Fri, Apr 2, 2021 at 11:00 AM Shuah Khan <skhan@linuxfoundation.org> wrote:
>>
>> On 4/2/21 3:32 AM, Brendan Higgins wrote:
>>>> TL;DR
>>>> $ ./tools/testing/kunit/kunit.py run --kunitconfig=lib/kunit
>>>>
>>>> Per suggestion from Ted [1], we can reduce the amount of typing by
>>>> assuming a convention that these files are named '.kunitconfig'.
>>>>
>>>> In the case of [1], we now have
>>>> $ ./tools/testing/kunit/kunit.py run --kunitconfig=fs/ext4
>>>>
>>>> Also add in such a fragment for kunit itself so we can give that as an
>>>> example more close to home (and thus less likely to be accidentally
>>>> broken).
>>>>
>>>> [1] https://lore.kernel.org/linux-ext4/YCNF4yP1dB97zzwD@mit.edu/
>>>>
>>>> Signed-off-by: Daniel Latypov <dlatypov@google.com>
>>>
>>> Reviewed-by: Brendan Higgins <brendanhiggins@google.com>
>>>
>>
>> Should this be captured in  documentation. Especially since this
>> is file is .* file.
>>
>> Do you want to include doc in this patch? Might be better that way.
> 
> It definitely should be documented, yes.
> The only real example hadn't landed yet when I sent this patch
> (fs/ext4/.kunitconfig was going in through the ext4 tree), but now
> it's in linus/master.
> 
> There's still some uncertainties about what best practices for this
> feature should be, i.e.
> * how granular should these be?
> * how should configs in parent dirs be handled? Should they be
> supersets of all the subdirs?
>      * E.g. should fs/.kunitconfig be a superset of
> fs/ext4/.kunitconfig and any other hypothetical subdir configs?
>      * Should we wait on saying "you should do this" until we have
> "import" statements/other mechanisms to make this less manual?
> * how should we handle non-UML tests, like the KASAN tests?
>    * ideally, kunit.py run will eventually support running tests on x86
> (using qemu)
> 
> If it's fine with you, I was hoping to come back and add a section to
> kunit/start.rst when we've had some of those questions more figured
> out.
> 

Sound good. I will apply this patch and you can document later.

thanks,
-- Shuah