linux-kernel - Re: [PATCH v2 00/17] 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]

Date:   Wed, 8 May 2019 19:18:30 -0700
From:   Frank Rowand <frowand.list@...il.com>
To:     Theodore Ts'o <tytso@....edu>,
        Greg KH <gregkh@...uxfoundation.org>,
        Brendan Higgins <brendanhiggins@...gle.com>,
        keescook@...gle.com, kieran.bingham@...asonboard.com,
        mcgrof@...nel.org, robh@...nel.org, sboyd@...nel.org,
        shuah@...nel.org, 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,
        dan.j.williams@...el.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, richard@....at, rientjes@...gle.com,
        rostedt@...dmis.org, wfg@...ux.intel.com
Subject: Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit
 testing framework

On 5/8/19 6:44 PM, Theodore Ts'o wrote:
> On Wed, May 08, 2019 at 05:58:49PM -0700, Frank Rowand wrote:
>>
>> If KUnit is added to the kernel, and a subsystem that I am submitting
>> code for has chosen to use KUnit instead of kselftest, then yes, I do
>> *have* to use KUnit if my submission needs to contain a test for the
>> code unless I want to convince the maintainer that somehow my case
>> is special and I prefer to use kselftest instead of KUnittest.
> 
> That's going to be between you and the maintainer.  Today, if you want
> to submit a substantive change to xfs or ext4, you're going to be
> asked to create test for that new feature using xfstests.  It doesn't
> matter that xfstests isn't in the kernel --- if that's what is
> required by the maintainer.

Yes, that is exactly what I was saying.

Please do not cut the pertinent parts of context that I am replying to.


>>> supposed to be a simple way to run a large number of small tests that
>>> for specific small components in a system.
>>
>> kselftest also supports running a subset of tests.  That subset of tests
>> can also be a large number of small tests.  There is nothing inherent
>> in KUnit vs kselftest in this regard, as far as I am aware.


> The big difference is that kselftests are driven by a C program that
> runs in userspace.  Take a look at tools/testing/selftests/filesystem/dnotify_test.c
> it has a main(int argc, char *argv) function.
> 
> In contrast, KUnit are fragments of C code which run in the kernel;
> not in userspace.  This allows us to test internal functions inside
> complex file system (such as the block allocator in ext4) directly.
> This makes it *fundamentally* different from kselftest.

No, totally incorrect.  kselftests also supports in kernel modules as
I mention in another reply to this patch.

This is talking past each other a little bit, because your next reply
is a reply to my email about modules.

-Frank

> 
> Cheers,
> 
> 						- Ted
>