From: Randy Dunlap <rdunlap@infradead.org>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: Brendan Higgins <brendanhiggins@google.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Shuah Khan <skhan@linuxfoundation.org>,
Iurii Zaikin <yzaikin@google.com>,
Paolo Abeni <pabeni@redhat.com>,
Matthieu Baerts <matthieu.baerts@tessares.net>,
linux-ext4@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
David Gow <davidgow@google.com>
Subject: Re: [PATCH] ext: EXT4_KUNIT_TESTS should depend on EXT4_FS instead of selecting it
Date: Wed, 21 Oct 2020 20:55:36 -0700 [thread overview]
Message-ID: <04d63aa1-ec2b-e6d2-5b51-6c05c5338ded@infradead.org> (raw)
In-Reply-To: <20201022034343.GQ181507@mit.edu>
On 10/21/20 8:43 PM, Theodore Y. Ts'o wrote:
> On Wed, Oct 21, 2020 at 04:07:15PM -0700, Randy Dunlap wrote:
>>> I'm don't particularly care how this gets achieved, but please think
>>> about how to make it easy for a kernel developer to run a specific set
>>> of subsystem unit tests. (In fact, being able to do something like
>>> "kunit.py run fs/ext4 fs/jbd2" or maybe "kunit.py run fs/..." would be
>>> *great*. No need to fuss with hand editing the .kunitconfig file at
>>> all would be **wonderful**.
>>
>> I understand the wish for ease of use, but this is still the tail
>> wagging the dog.
>>
>> The primary documentation for 'select' is
>> Documentation/kbuild/kconfig-language.rst, which says:
>>
>> Note:
>> select should be used with care. select will force
>> a symbol to a value without visiting the dependencies.
>> By abusing select you are able to select a symbol FOO even
>> if FOO depends on BAR that is not set.
>> In general use select only for non-visible symbols
>> (no prompts anywhere) and for symbols with no dependencies.
>> That will limit the usefulness but on the other hand avoid
>> the illegal configurations all over.
>>
>
> Well, the KUNIT configs are kinda of a special case, since normally
> they don't have a lot of huge number of dependencies, since unit tests
> in general are not integration tests. So ideally, dependencies will
> mostly be replaced with mocking functions. And if there are *real*
> dependencies that the Kunit Unit tests need, they can be explicitly
> pulled in with selects.
>
> That being said, as I said, I'm not picky about *how* this gets
> achieved. But ease of use is a key part of making people more likely
> to run the unit tests. So another way of solving the problem might be
> to put some kind of automated dependency solver into kunit.py, or some
> way of manually adding the necessary dependencies in some kind of
> Kunitconfig file that are in directories where their are Unit tests,
> or maybe some kind of extenstion to the Kconfig file. My main
> requirement is that the only thing that should be necessary for
> enabling the ext4 Kunit tests should be adding a single line to the
> .kunitconfig file. It's not fair to make the human developer manually
> have to figure out the dependency chains.
>
> As far as I'm concerned, ease of use is important enough to justfy
> special casing and/or bending the rules as far as "select" is concered
> for Kunit-related CONFIG items. But if someone else want to suggest a
> better approach, I'm all ears.
>
> Cheers,
Indeed. For the record, I support testing and have for a long time.
I just don't care for this big fscking hammer approach.
But I doubt that I can change your mind.
g'day.
--
~Randy
next prev parent reply other threads:[~2020-10-22 3:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-20 7:37 [PATCH] ext: EXT4_KUNIT_TESTS should depend on EXT4_FS instead of selecting it Geert Uytterhoeven
2020-10-21 21:15 ` Brendan Higgins
2020-10-21 21:16 ` Randy Dunlap
2020-10-21 22:36 ` Theodore Y. Ts'o
2020-10-21 23:07 ` Randy Dunlap
2020-10-22 3:43 ` Theodore Y. Ts'o
2020-10-22 3:55 ` Randy Dunlap [this message]
2020-10-22 7:20 ` Geert Uytterhoeven
2020-10-22 23:52 ` Brendan Higgins
2020-10-23 14:07 ` Theodore Y. Ts'o
2020-10-24 5:53 ` David Gow
2020-10-21 21:29 ` David Gow
2020-10-21 21:30 ` Randy Dunlap
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=04d63aa1-ec2b-e6d2-5b51-6c05c5338ded@infradead.org \
--to=rdunlap@infradead.org \
--cc=adilger.kernel@dilger.ca \
--cc=brendanhiggins@google.com \
--cc=davidgow@google.com \
--cc=geert@linux-m68k.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthieu.baerts@tessares.net \
--cc=pabeni@redhat.com \
--cc=skhan@linuxfoundation.org \
--cc=tytso@mit.edu \
--cc=yzaikin@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).