archive mirror
 help / color / mirror / Atom feed
From: Luis Chamberlain <>
To: Greg KH <>,
	Shuah Khan <>
Subject: Re: [PATCH v2 1/4] selftests: add tests_sysfs module
Date: Thu, 22 Jul 2021 15:34:49 -0700	[thread overview]
Message-ID: <20210722223449.ot5272wpc6o5uzlk@garbanzo> (raw)
In-Reply-To: <>

On Wed, Jul 21, 2021 at 01:32:41PM +0200, Greg KH wrote:
> On Fri, Jul 02, 2021 at 05:46:29PM -0700, Luis Chamberlain wrote:
> > This selftests will shortly be expanded upon with more tests which
> > require further kernel changes in order to provide better test
> > coverage.
> Why is this not using kunit?  We should not be adding new in-kernel
> tests that are not using that api anymore.

No way. That cannot possibly be true. When was this decided? Did
Shuah Khan, the maintainer of selftests, all of a sudden decide we
are going to deprecate selftests in favor for trying to only use
kunit? Did we have a conference where this was talked about and decided?

If so all these are huge news to me and I missed the memo!

If I would have been at such meeting I would have definitely yelled
bloody murder!

kunit relies on UML and UML is a simple one core architecture, to start
with. This means I cannot run tests for multicore with it, which is
where many races do happen! Yes, you can run kunit on other
architectures, but all that is new.

Second, I did help review kunit getting upstream, and suggested a few
example tests, part of which were for sysctl to compare and contrast
what is possible and what we cannot do.

Not everything we want to test should be written as a kunit test.
No way.

In this case kunit is not ideal given I want to mimic something in
userspace interaction, and expose races through error injection and
if we can use as many cores to busy races out.

Trust me, I'm an advocate of kunit, and I'm even trying to see ideally
what tests from fstests / blktests could be kunit'ified. But in this
case, no. Using a selftests is much better target framework.

> > diff --git a/lib/test_sysfs.c b/lib/test_sysfs.c
> > new file mode 100644
> > index 000000000000..bf43016d40b5
> > --- /dev/null
> > +++ b/lib/test_sysfs.c
> > @@ -0,0 +1,943 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> This does not match your "boiler-plate" text below, sorry.

Indeed, I'll fix it.


  reply	other threads:[~2021-07-22 22:34 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-03  0:46 [PATCH v2 0/4] selftests: add a new test driver for sysfs Luis Chamberlain
2021-07-03  0:46 ` [PATCH v2 1/4] selftests: add tests_sysfs module Luis Chamberlain
2021-07-21 11:32   ` Greg KH
2021-07-22 22:34     ` Luis Chamberlain [this message]
2021-07-23 10:38       ` Greg KH
2021-07-23 17:32         ` Luis Chamberlain
2021-07-03  0:46 ` [PATCH v2 2/4] kernfs: add initial failure injection support Luis Chamberlain
2021-07-03  0:46 ` [PATCH v2 3/4] test_sysfs: add support to use kernfs failure injection Luis Chamberlain
2021-07-03  0:46 ` [PATCH v2 4/4] test_sysfs: demonstrate deadlock fix Luis Chamberlain
2021-07-03  4:49   ` Greg KH
2021-07-03 17:28     ` Luis Chamberlain
2021-07-21 11:33       ` Greg KH
2021-07-22 22:36         ` Luis Chamberlain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210722223449.ot5272wpc6o5uzlk@garbanzo \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).