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: <CABVgOSnkxgeXXXm9xp5_PvBxtMGbyFN-Jmd6YJ1u6g81MF_fyw@mail.gmail.com>
Date: Tue, 30 Jul 2024 18:10:55 +0800
From: David Gow <davidgow@...gle.com>
To: Randy Dunlap <rdunlap@...radead.org>
Cc: Muhammad Usama Anjum <usama.anjum@...labora.com>, Yury Norov <yury.norov@...il.com>, 
	Andrew Morton <akpm@...ux-foundation.org>, Rasmus Villemoes <linux@...musvillemoes.dk>, 
	Shuah Khan <shuah@...nel.org>, linux-kernel@...r.kernel.org, 
	linux-kselftest@...r.kernel.org, kees@...nel.org, 
	John Hubbard <jhubbard@...dia.com>, kernel@...labora.com
Subject: Re: [PATCH 2/3] bitmap: Rename module

On Mon, 29 Jul 2024 at 22:09, Randy Dunlap <rdunlap@...radead.org> wrote:
>
>
>
> On 7/29/24 1:07 AM, Muhammad Usama Anjum wrote:
> > On 7/27/24 10:35 PM, Yury Norov wrote:
> >> On Fri, Jul 26, 2024 at 04:06:57PM +0500, Muhammad Usama Anjum wrote:
> >>> Rename module to bitmap_kunit and rename the configuration option
> >>> compliant with kunit framework.
> >>
> >> ... , so those enabling bitmaps testing in their configs by setting
> >> "CONFIG_TEST_BITMAP=y" will suddenly get it broken, and will likely
> >> not realize it until something nasty will happen.
> > CONFIG_TEST_BITMAP was being enabled by the kselftest suite lib. The bitmap
> > test and its config option would disappear. The same test can be run by
> > just enabling KUNIT default config option:
> >
> > KUNIT_ALL_TESTS=y enables this bitmap config by default.
> >
> >>
> >> Sorry, NAK for config rename.
> >>
>
> I agree with Yury. Using KUNIT takes away test coverage for people who
> are willing to run selftests but not use KUNIT.

I can see the point that renaming the config option is just churn, but
is there a reason people would run the bitmap selftest but be unable
or unwilling to use KUnit?

Beyond a brief period of adjustment (which could probably be made
quite minimal with a wrapper script or something), there shouldn't
really be any fundamental difference: KUnit tests can already run at
boot, be configured with a config option, and write output to the
kernel log. There's nothing really being taken away here, and the
bonus of having easier access to run the tests with KUnit's tooling
(or have them automatically run by systems which run KUnit tests)
would seem worthwhile to me, especially since it's optional. And
CONFIG_KUNIT shouldn't be heavy enough to cause problems.

Obviously I can't force people to use KUnit, but this is exactly the
sort of test which would fit KUnit well, and -- forgive me if I'm
missing something -- the only real argument against it I'm hearing is
"it's different". And while that's valid (as I said, churn for churn's
sake isn't great), none of the "people who are willing to run
selftests but not use KUnit" have given reasons why. Especially since
this is the sort of test (testing in-kernel functions) we're
encouraging people to write with KUnit in
Documentation/dev-tools/testing-overview.rst -- if there are good
reasons people are refusing to run these, maybe we need to fix those
or change the recommendation.

-- David

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4014 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ