lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Wed, 20 Nov 2019 13:56:52 +0000 (GMT)
From:   Alan Maguire <>
To:     Brendan Higgins <>
cc:     Alan Maguire <>,
        David Gow <>,
        Iurii Zaikin <>,
        "Theodore Ts'o" <>, Kees Cook <>,
        Shuah Khan <>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        Linux Kernel Mailing List <>,
        KUnit Development <>,
        Andrew Morton <>,
        Masahiro Yamada <>,,,,,,
        Jonathan Corbet <>,,
        Luis Chamberlain <>,,
        "open list:DOCUMENTATION" <>,
        Stephen Boyd <>,
        Knut Omang <>
Subject: Re: [PATCH v4 linux-kselftest-test 3/6] kunit: allow kunit tests to
 be loaded as a module

On Tue, 19 Nov 2019, Brendan Higgins wrote:

> On Fri, Nov 15, 2019 at 2:16 AM Alan Maguire <> wrote:
> >
> > As tests are added to kunit, it will become less feasible to execute
> > all built tests together.  By supporting modular tests we provide
> > a simple way to do selective execution on a running system; specifying
> >
> >
> > ...means we can simply "insmod example-test.ko" to run the tests.
> >
> > To achieve this we need to do the following:
> >
> > o export the required symbols in kunit
> > o string-stream tests utilize non-exported symbols so for now we skip
> >   building them when CONFIG_KUNIT_TEST=m.
> > o support a new way of declaring test suites.  Because a module cannot
> >   do multiple late_initcall()s, we provide a kunit_test_suites() macro
> >   to declare multiple suites within the same module at once.
> > o some test module names would have been too general ("test-test"
> >   and "example-test" for kunit tests, "inode-test" for ext4 tests);
> >   rename these as appropriate ("kunit-test", "kunit-example-test"
> >   and "ext4-inode-test" respectively).
> Hmm...should we maybe apply this naming scheme to all the tests then?
> I think Kees might have suggested this. I am actually not sure whether
> or not we should and would like to get other people's input.

I'd be interested in other opinions here too; the approach I took here was 
to apply the convention [subsystem]-[optional-suite]-test.ko. So for 
example kunit-test.ko because the subsystem under test is kunit, etc.
Implicit in this is the reasoning that the framework used isn't relevant 
to the naming of the test module, but I'm happy to tweak the naming 
scheme if another approach is preferred.  The current names from the 
patchset are:

kunit-test.ko		- tests for kunit itself
kunit-example-test.ko	- example test using the kunit framework
sysctl-test.ko		- sysctl kunit tests
list-test.ko		- list kunit tests
ext4-inode-test.ko	- ext4 kunit tests
> It is a valid point that test-test or example-test are too general of
> names for modules, but if this is the case, I think that inode-test is
> probably too general as well. But if we are going that far, maybe we
> should rename everything *-kunit-test.c.

Yep, I figured inode-test.ko was too general also, so the Makefile 
builds ext4-inode-test.ko from inode-test.c. See fs/ext4/Makefile.



Powered by blists - more mailing lists