Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp5413063pxu; Thu, 22 Oct 2020 01:20:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwuT4gBWX3GPm4STeojYs26y3gDs/BES9vM7ffo5EHSk3G6U+Qb+te4/h5GYu/usDLCy8jf X-Received: by 2002:a17:906:11d3:: with SMTP id o19mr1121002eja.287.1603354835075; Thu, 22 Oct 2020 01:20:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603354835; cv=none; d=google.com; s=arc-20160816; b=oiICwxEZz32hZG43NT1IhwD3X7T+obe8nutyhVKBnLWRAScU+v0xtNmkUGRzzY02QF 6/c9KVrnRXBVfKJNz2O6r7dgdKr9nUwzCHiuIn3pPq5MDlGvWBN+w8EVeoCYW7s5nh2H O1SISFki85KJAqWARyisjfgjAzl9KgZCUy63y7gnoaaT+d5tTYyY00CTGLEE9hDNcFVh v73UpXXkaVJ184/XHps/9pR2OuEzMp9i1c1YCEGAGBPAxcCUc7yPMWhd7bWP0UBCfDGZ 4vwy+fX3HvT8Gc4CAl9dSF2+WRr8BQfgamOcCnNoxHP/4cImeydL4fEAywZxNeMLbTbs 5cng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=rt4pLoPrnZVb/DEAuSl17Zgah/8EdaFszuU4+ugY8yQ=; b=r0H2yRCp8z4CrlV5bISyKTJpiRkBtf4GYYzCjVXouy05U6wEHdBrg0yBtNZ/UurhjO kTN15wzOBOE8BSBQcxmGr7iXpbJMr3wX5hPqC8Vx1V9FGb2hqxZMdgYJUH4ycaAmk039 SytDDwxp8GLlkF+4LrcnRDMNTDMpECYV/45IhSa9voQzKCfjMNZ8IRUkRxXVW/14sGiZ 1qgG9+QLSvbNC13YyNWVMaZ2NefqIRgx7yNW1YZk40M98CxLm0W+kU190foDAR5hxLxq EyAb9qCy9/TC665XFUY9Bdzj99Kx9UwCLLGcyzzH/FG1JVBj5PXNI+YHWQXLwyypjUng IU3w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a20si423797ejb.550.2020.10.22.01.20.09; Thu, 22 Oct 2020 01:20:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2443345AbgJVDoA (ORCPT + 99 others); Wed, 21 Oct 2020 23:44:00 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:49335 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2443118AbgJVDn7 (ORCPT ); Wed, 21 Oct 2020 23:43:59 -0400 Received: from callcc.thunk.org (pool-72-74-133-215.bstnma.fios.verizon.net [72.74.133.215]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09M3hhpx012820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Oct 2020 23:43:43 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id 2C055420107; Wed, 21 Oct 2020 23:43:43 -0400 (EDT) Date: Wed, 21 Oct 2020 23:43:43 -0400 From: "Theodore Y. Ts'o" To: Randy Dunlap Cc: Brendan Higgins , Geert Uytterhoeven , Andreas Dilger , Shuah Khan , Iurii Zaikin , Paolo Abeni , Matthieu Baerts , linux-ext4@vger.kernel.org, Linux Kernel Mailing List , David Gow Subject: Re: [PATCH] ext: EXT4_KUNIT_TESTS should depend on EXT4_FS instead of selecting it Message-ID: <20201022034343.GQ181507@mit.edu> References: <20201020073740.29081-1-geert@linux-m68k.org> <20201021223649.GP181507@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org 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, - Ted