On Fri, Apr 23, 2021 at 4:39 AM Nico Pache <npache@xxxxxxxxxx> wrote: > > On 4/18/21 3:39 PM, Theodore Ts'o wrote: > > > On Wed, Apr 14, 2021 at 04:58:03AM -0400, Nico Pache wrote: > >> There are few instances of KUNIT tests that are not properly defined. > >> This commit focuses on correcting these issues to match the standard > >> defined in the Documentation. > > The word "standard" seems to be over-stating things. The > > documentation currently states, "they _usually_ have config options > > ending in ``_KUNIT_TEST'' (emphasis mine). I can imagine that there > > might be some useful things we can do from a tooling perspective if we > > do standardize things, but if you really want to make it a "standard", > > we should first update the manpage to say so, > > KUNIT Maintainers, should we go ahead and make this the "standard"? > > As Ted has stated... consistency with 'grep' is my desired outcome. > The intention here is for this to be a "standard", with the caveat that there may be reasons for not following said standard, though they should be rare and may result in incompatibility with some tooling. This is broadly laid out in the opening of the Development/dev-tools/style.rst document, albeit still referring to "guidelines" rather than a "standard". The rest of the document does, as Ted pointed out, become more descriptive than prescriptive in some sections (like the Kconfig entry one): assuming no-one is particularly unhappy with that being tightened up, I've no problem with rewording it. That being said, when it comes to tooling, the Kconfig name does seem like it's less important than it could've been: the existence of a KUNIT_ALL_TESTS option, as well as support for having per-directory/per-subsystem .kunitconfig files should hopefully mean there's no need for tools to search for entries ending in _KUNIT_TEST. (I do agree that it makes using 'grep' more convenient, though.) > > and explain why (e.g., > > so that we can easily extract out all of the kunit test modules, and > > perhaps paint a vision of what tools might be able to do with such a > > standard). > > > > Alternatively, the word "standard" could perhaps be changed to > > "convention", which I think more accurately defines how things work at > > the moment. Cheers, -- David
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
