linux-kernel - Re: [PATCH v5 00/18] kunit: introduce KUnit, the Linux kernel unit testing framework

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <20190626023809.GW19023@42.do-not-panic.com>
Date:   Wed, 26 Jun 2019 02:38:09 +0000
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     Frank Rowand <frowand.list@...il.com>
Cc:     Brendan Higgins <brendanhiggins@...gle.com>,
        gregkh@...uxfoundation.org, jpoimboe@...hat.com,
        keescook@...gle.com, kieran.bingham@...asonboard.com,
        peterz@...radead.org, robh@...nel.org, sboyd@...nel.org,
        shuah@...nel.org, tytso@....edu, yamada.masahiro@...ionext.com,
        devicetree@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        kunit-dev@...glegroups.com, linux-doc@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-kbuild@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
        linux-nvdimm@...ts.01.org, linux-um@...ts.infradead.org,
        Alexander.Levin@...rosoft.com, Tim.Bird@...y.com,
        amir73il@...il.com, dan.carpenter@...cle.com, daniel@...ll.ch,
        jdike@...toit.com, joel@....id.au, julia.lawall@...6.fr,
        khilman@...libre.com, knut.omang@...cle.com, logang@...tatee.com,
        mpe@...erman.id.au, pmladek@...e.com, rdunlap@...radead.org,
        richard@....at, rientjes@...gle.com, rostedt@...dmis.org,
        wfg@...ux.intel.com
Subject: Re: [PATCH v5 00/18] kunit: introduce KUnit, the Linux kernel unit
 testing framework

On Wed, Jun 19, 2019 at 06:17:51PM -0700, Frank Rowand wrote:
> It does not matter whether KUnit provides additional things, relative
> to kselftest.  The point I was making is that there appears to be
> _some_ overlap between kselftest and KUnit, and if there is overlap
> then it is worth considering whether the overlap can be unified instead
> of duplicated.

>From my experience as an author of several kselftests drivers, one
faily complex, and after reviewing the sysctl kunit test module, I
disagree with this.

Even if there were an overlap, I'd say let the best test harness win.
Just as we have different LSMs that do something similar.

But this is not about that though. Although both are testing code,
they do so in *very* different ways.

The design philosophy and architecture are fundamentally different. The
*only* thing I can think of where there is overlap is that both can test
similar code paths. Beyond that, the layout of how one itemizes tests
could be borrowed, but that would be up to each kselftest author to
decide, in fact some ksefltests do exist which follow similar pattern of
itemizing test cases and running them. Kunit just provides a proper
framework to do this easily but also with a focus on UML. This last
aspect makes kselftests fundamentally orthogonal from an architecture /
design perspective.

After careful review, I cannot personally identify what could be shared
at this point. Can you? If you did identify one part, how do you
recommend to share it?

  Luis