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] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 23 Oct 2020 10:07:44 -0400
From:   "Theodore Y. Ts'o" <>
To:     Brendan Higgins <>
Cc:     Randy Dunlap <>,
        Geert Uytterhoeven <>,
        Andreas Dilger <>,
        Shuah Khan <>,
        Iurii Zaikin <>,
        Paolo Abeni <>,
        Matthieu Baerts <>,,
        Linux Kernel Mailing List <>,
        David Gow <>
Subject: Re: [PATCH] ext: EXT4_KUNIT_TESTS should depend on EXT4_FS instead
 of selecting it

On Thu, Oct 22, 2020 at 04:52:52PM -0700, Brendan Higgins wrote:
> So you, me, Luis, David, and a whole bunch of other people have been
> thinking about this problem for a while. What if we just put
> kunitconfig fragments in directories along side the test files they
> enable?
> For example, we could add a file to fs/ext4/kunitconfig which contains:
> We could do something similar in fs/jdb2, etc.
> Obviously some logically separate KUnit tests (different maintainers,
> different Kconfig symbols, etc) reside in the same directory, for
> these we could name the kunitconfig file something like
> lib/list-test.kunitconfig (not a great example because lists are
> always built into Linux), but you get the idea.
> Then like Ted suggested, if you call run foo/bar, then
> if bar is a directory, then will look for foo/bar/kunitconfig
> if bar is a file ending with .kunitconfig like foo/bar.kunitconfig,
> then it will use that kunitconfig
> if bar is '...' (foo/...) then will look for all kunitconfigs
> underneath foo.
> Once all the kunitconfigs have been resolved, they will be merged into
> the .kunitconfig. If they can be successfully merged together, the new
> .kunitconfig will then continue to function as it currently does.

I was thinking along a similar set of lines this morning.  One thing
I'd add in addition to your suggestion to that is to change how
.kunitconfig is interpreted such that


is always implied, so it doesn't have to be specified explicitly, and
that if a line like:




etc. occurs, that will cause a include of the Kunitconfig (I'd using a
capitalized version of the filename like Kconfig, so that it's easier
to see in a directory listing) in the named directory.

That way, .kunitconfig is backwards compatible, but it also allows
people to put a one-liner into .kunitconfig to enable the unit tests
for that particular directory.

What do folks think?


						- Ted

Powered by blists - more mailing lists