linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 16:07:15 -0700	[thread overview]
Message-ID: <b51d57fd-061a-26f3-5ecc-8efecbc95a49@infradead.org> (raw)
In-Reply-To: <20201021223649.GP181507@mit.edu>

On 10/21/20 3:36 PM, Theodore Y. Ts'o wrote:
> On Wed, Oct 21, 2020 at 02:16:56PM -0700, Randy Dunlap wrote:
>> On 10/21/20 2:15 PM, Brendan Higgins wrote:
>>> On Tue, Oct 20, 2020 at 12:37 AM Geert Uytterhoeven
>>> <geert@linux-m68k.org> wrote:
>>>>
>>>> EXT4_KUNIT_TESTS selects EXT4_FS, thus enabling an optional feature the
>>>> user may not want to enable.  Fix this by making the test depend on
>>>> EXT4_FS instead.
>>>>
>>>> Fixes: 1cbeab1b242d16fd ("ext4: add kunit test for decoding extended timestamps")
>>>> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
>>>
>>> If I remember correctly, having EXT4_KUNIT_TESTS select EXT4_FS was
>>> something that Ted specifically requested, but I don't have any strong
>>> feelings on it either way.
>>
>> omg, please No. depends on is the right fix here.
> 
> So my requirement which led to that particular request is to keep what
> needs to be placed in .kunitconfig to a small and reasonable set.
> 
> Per Documentation/dev-tools/kunit, we start by:
> 
>     cd $PATH_TO_LINUX_REPO
>     cp arch/um/configs/kunit_defconfig .kunitconfig
> 
> we're then supposed to add whatever Kunit tests we want to enable, to wit:
> 
> CONFIG_EXT4_KUNIT_TESTS=y
> 
> so that .kunitconfig would look like this:
> 
> CONFIG_KUNIT=y
> CONFIG_KUNIT_TEST=y
> CONFIG_KUNIT_EXAMPLE_TEST=y
> CONFIG_EXT4_KUNIT_TESTS=y
> 
> ... and then you should be able to run:
> 
> ./tools/testing/kunit/kunit.py run
> 
> ... and have the kunit tests run.  I would *not* like to have to put a
> huge long list of CONFIG_* dependencies into the .kunitconfig file.
> 
> 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.


-- 
~Randy


  reply	other threads:[~2020-10-21 23:07 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 [this message]
2020-10-22  3:43         ` Theodore Y. Ts'o
2020-10-22  3:55           ` Randy Dunlap
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=b51d57fd-061a-26f3-5ecc-8efecbc95a49@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).