On Fri, Apr 2, 2021 at 11:00 AM Shuah Khan <skhan@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxx/ > >> > >> Signed-off-by: Daniel Latypov <dlatypov@xxxxxxxxxx> > > > > Reviewed-by: Brendan Higgins <brendanhiggins@xxxxxxxxxx> > > > > 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. > > thanks, > -- Shuah
