linux-kernel - Re: [PATCH v2 linux-kselftest-test 0/3] kunit: support building core/tests as modules

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:   Mon, 14 Oct 2019 09:20:51 +0000
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     Alan Maguire <alan.maguire@...cle.com>
Cc:     linux-kselftest@...r.kernel.org, brendanhiggins@...gle.com,
        skhan@...uxfoundation.org, keescook@...omium.org,
        yzaikin@...gle.com, akpm@...ux-foundation.org,
        yamada.masahiro@...ionext.com, catalin.marinas@....com,
        joe.lawrence@...hat.com, penguin-kernel@...ove.sakura.ne.jp,
        schowdary@...dia.com, urezki@...il.com,
        andriy.shevchenko@...ux.intel.com, changbin.du@...el.com,
        kunit-dev@...glegroups.com, linux-kernel@...r.kernel.org,
        linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v2 linux-kselftest-test 0/3] kunit: support building
 core/tests as modules

On Tue, Oct 08, 2019 at 03:55:43PM +0100, Alan Maguire wrote:
> The current kunit execution model is to provide base kunit functionality
> and tests built-in to the kernel.  The aim of this series is to allow
> building kunit itself and tests as modules.  This in turn allows a
> simple form of selective execution; load the module you wish to test.
> In doing so, kunit itself (if also built as a module) will be loaded as
> an implicit dependency.
> 
> Because this requires a core API modification - if a module delivers
> multiple suites, they must be declared with the kunit_test_suites()
> macro - we're proposing this patch as a candidate to be applied to the
> test tree before too many kunit consumers appear.  We attempt to deal
> with existing consumers in patch 1.

This is neat and makes sense to me. However the ordering of the patches
seems odd. If modules depend on kunit module, then shouldn't that go
first? Ie, we want this to be bisectable in proper order.

  Luis