kunit: Fix formatting of KUNIT tests to meet the standard

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.

Issues Fixed:
- tests should end in KUNIT_TEST, some fixes have been applied to correct issues were KUNIT_TESTS is used or KUNIT is not mentioned.
- Tests should default to KUNIT_ALL_TESTS
- Tests configs tristate should have if !KUNIT_ALL_TESTS

No functional changes other than CONFIG name changes

Changes since v2:
- Split patch 1 by subcomponents
- fix issues where config was *KUNIT_TEST_TEST
- properly threaded/chained messages

Nico Pache (6):
kunit: ASoC: topology: adhear to KUNIT formatting standard
kunit: software node: adhear to KUNIT formatting standard
kunit: ext4: adhear to KUNIT formatting standard
kunit: lib: adhear to KUNIT formatting standard
kunit: mptcp: adhear to KUNIT formatting standard
m68k: update configs to match the proper KUNIT syntax

 arch/m68k/configs/amiga_defconfig    |  6 +++---
 arch/m68k/configs/apollo_defconfig   |  6 +++---
 arch/m68k/configs/atari_defconfig    |  6 +++---
 arch/m68k/configs/bvme6000_defconfig |  6 +++---
 arch/m68k/configs/hp300_defconfig    |  6 +++---
 arch/m68k/configs/mac_defconfig      |  6 +++---
 arch/m68k/configs/multi_defconfig    |  6 +++---
 arch/m68k/configs/mvme147_defconfig  |  6 +++---
 arch/m68k/configs/mvme16x_defconfig  |  6 +++---
 arch/m68k/configs/q40_defconfig      |  6 +++---
 arch/m68k/configs/sun3_defconfig     |  6 +++---
 arch/m68k/configs/sun3x_defconfig    |  6 +++---
 drivers/base/test/Kconfig            |  2 +-
 drivers/base/test/Makefile           |  2 +-
 fs/ext4/.kunitconfig                 |  2 +-
 fs/ext4/Kconfig                      |  2 +-
 fs/ext4/Makefile                     |  2 +-
 lib/Kconfig.debug                    | 21 +++++++++++++--------
 lib/Makefile                         |  6 +++---
 net/mptcp/Kconfig                    |  2 +-
 net/mptcp/Makefile                   |  2 +-
 net/mptcp/crypto.c                   |  2 +-
 net/mptcp/token.c                    |  2 +-
 sound/soc/Kconfig                    |  2 +-
 sound/soc/Makefile                   |  4 ++--
 25 files changed, 64 insertions(+), 59 deletions(-)

2.30.2

Drop 'S' from end of SND_SOC_TOPOLOGY_KUNIT_TESTS inorder to adhear to
the KUNIT *_KUNIT_TEST config name format.

---
 sound/soc/Kconfig  | 2 +-
 sound/soc/Makefile | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

index 640494f76cbd..8a13462e1a63 100644
@@ -37,7 +37,7 @@ config SND_SOC_COMPRESS
 config SND_SOC_TOPOLOGY
 	bool
 
-config SND_SOC_TOPOLOGY_KUNIT_TESTS
+config SND_SOC_TOPOLOGY_KUNIT_TEST
 	tristate "KUnit tests for SoC topology"
 	depends on KUNIT
 	depends on SND_SOC_TOPOLOGY

index f56ad996eae8..a7b37c06dc43 100644
@@ -7,9 +7,9 @@ ifneq ($(CONFIG_SND_SOC_TOPOLOGY),)
 snd-soc-core-objs += soc-topology.o
 endif
 
-ifneq ($(CONFIG_SND_SOC_TOPOLOGY_KUNIT_TESTS),)
+ifneq ($(CONFIG_SND_SOC_TOPOLOGY_KUNIT_TEST),)
 # snd-soc-test-objs := soc-topology-test.o
-obj-$(CONFIG_SND_SOC_TOPOLOGY_KUNIT_TESTS) := soc-topology-test.o
+obj-$(CONFIG_SND_SOC_TOPOLOGY_KUNIT_TEST) := soc-topology-test.o
 endif
 
 ifneq ($(CONFIG_SND_SOC_GENERIC_DMAENGINE_PCM),)

2.30.2

Please submit patches using subject lines reflecting the style for the subsystem, this makes it easier for people to identify relevant patches. Look at what existing commits in the area you're changing are doing and make sure your subject lines visually resemble what they're doing. There's no need to resubmit to fix this alone.

Change CONFIG_KUNIT_DRIVER_PE_TEST to CONFIG_DRIVER_PE_KUNIT_TEST inorder to adhear to the KUNIT *_KUNIT_TEST config name format.

---
 drivers/base/test/Kconfig  | 2 +-
 drivers/base/test/Makefile | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

index ba225eb1b761..2f3fa31a948e 100644
@@ -8,7 +8,7 @@ config TEST_ASYNC_DRIVER_PROBE
 	  The module name will be test_async_driver_probe.ko
 
 	  If unsure say N.
-config KUNIT_DRIVER_PE_TEST
+config DRIVER_PE_KUNIT_TEST
 	bool "KUnit Tests for property entry API" if !KUNIT_ALL_TESTS
 	depends on KUNIT=y
 	default KUNIT_ALL_TESTS

index 2f15fae8625f..64b2f3d744d5 100644
@@ -1,5 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_TEST_ASYNC_DRIVER_PROBE)	+= test_async_driver_probe.o
 
-obj-$(CONFIG_KUNIT_DRIVER_PE_TEST) += property-entry-test.o
+obj-$(CONFIG_DRIVER_PE_KUNIT_TEST) += property-entry-test.o
 CFLAGS_REMOVE_property-entry-test.o += -fplugin-arg-structleak_plugin-byref -fplugin-arg-structleak_plugin-byref-all

2.30.2

Drop 'S' from end of CONFIG_EXT4_KUNIT_TESTS inorder to adhear to the KUNIT *_KUNIT_TEST config name format.

---
 fs/ext4/.kunitconfig | 2 +-
 fs/ext4/Kconfig      | 2 +-
 fs/ext4/Makefile     | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

index bf51da7cd9fc..81d4da667740 100644
@@ -1,3 +1,3 @@
 CONFIG_KUNIT=y
 CONFIG_EXT4_FS=y
-CONFIG_EXT4_KUNIT_TESTS=y
+CONFIG_EXT4_KUNIT_TEST=y

index 86699c8cab28..1569d3872136 100644
@@ -101,7 +101,7 @@ config EXT4_DEBUG
 	  If you select Y here, then you will be able to turn on debugging
 	  using dynamic debug control for mb_debug() / ext_debug() msgs.
 
-config EXT4_KUNIT_TESTS
+config EXT4_KUNIT_TEST
 	tristate "KUnit tests for ext4" if !KUNIT_ALL_TESTS
 	depends on EXT4_FS && KUNIT
 	default KUNIT_ALL_TESTS

index 49e7af6cc93f..4e28e380d51b 100644
@@ -15,5 +15,5 @@ ext4-y	:= balloc.o bitmap.o block_validity.o dir.o ext4_jbd2.o extents.o \
 ext4-$(CONFIG_EXT4_FS_POSIX_ACL)	+= acl.o
 ext4-$(CONFIG_EXT4_FS_SECURITY)		+= xattr_security.o
 ext4-inode-test-objs			+= inode-test.o
-obj-$(CONFIG_EXT4_KUNIT_TESTS)		+= ext4-inode-test.o
+obj-$(CONFIG_EXT4_KUNIT_TEST)		+= ext4-inode-test.o
 ext4-$(CONFIG_FS_VERITY)		+= verity.o

2.30.2

Another spelling nit, that should be "in order".

This will break people who have existing .kunitconfig files, but if we are going to make this a standard (but please document it as a standard first!), might as well do it sooner rather than later.

Cheers,

- Ted

Change config names inorder to adhear to the KUNIT *KUNIT_TEST config name format.

Add 'if !KUNIT_ALL_TESTS' to the KUNIT config tristates inorder to adhear to the KUNIT standard.

add 'default KUNIT_ALL_TESTS' to the KUNIT config options inorder to adhear to the KUNIT standard.

---
 lib/Kconfig.debug | 21 +++++++++++++--------
 lib/Makefile      |  6 +++---
 2 files changed, 16 insertions(+), 11 deletions(-)

index 417c3d3e521b..e7a5f4cc6de1 100644
@@ -2279,9 +2279,10 @@ config TEST_SYSCTL
 
 	  If unsure, say N.
 
-config BITFIELD_KUNIT
-	tristate "KUnit test bitfield functions at runtime"
+config BITFIELD_KUNIT_TEST
+	tristate "KUnit test bitfield functions at runtime" if !KUNIT_ALL_TESTS
 	depends on KUNIT
+	default KUNIT_ALL_TESTS
 	help
 	  Enable this option to test the bitfield functions at boot.
 

@@ -2296,8 +2297,9 @@ config BITFIELD_KUNIT
 	  If unsure, say N.
 
 config RESOURCE_KUNIT_TEST
-	tristate "KUnit test for resource API"
+	tristate "KUnit test for resource API" if !KUNIT_ALL_TESTS
 	depends on KUNIT
+	default KUNIT_ALL_TESTS
 	help
 	  This builds the resource API unit test.
 	  Tests the logic of API provided by resource.c and ioport.h.

@@ -2337,9 +2339,10 @@ config LIST_KUNIT_TEST
 
 	  If unsure, say N.
 
-config LINEAR_RANGES_TEST
-	tristate "KUnit test for linear_ranges"
+config LINEAR_RANGES_KUNIT_TEST
+	tristate "KUnit test for linear_ranges" if !KUNIT_ALL_TESTS
 	depends on KUNIT
+	default KUNIT_ALL_TESTS
 	select LINEAR_RANGES
 	help
 	  This builds the linear_ranges unit test, which runs on boot.

@@ -2350,8 +2353,9 @@ config LINEAR_RANGES_TEST
 	  If unsure, say N.
 
 config CMDLINE_KUNIT_TEST
-	tristate "KUnit test for cmdline API"
+	tristate "KUnit test for cmdline API" if !KUNIT_ALL_TESTS
 	depends on KUNIT
+	default KUNIT_ALL_TESTS
 	help
 	  This builds the cmdline API unit test.
 	  Tests the logic of API provided by cmdline.c.

@@ -2360,9 +2364,10 @@ config CMDLINE_KUNIT_TEST
 
 	  If unsure, say N.
 
-config BITS_TEST
-	tristate "KUnit test for bits.h"
+config BITS_KUNIT_TEST
+	tristate "KUnit test for bits.h" if !KUNIT_ALL_TESTS
 	depends on KUNIT
+	default KUNIT_ALL_TESTS
 	help
 	  This builds the bits unit test.
 	  Tests the logic of macros defined in bits.h.

index b5307d3eec1a..ffa749c3b6e4 100644
@@ -347,10 +347,10 @@ obj-$(CONFIG_OBJAGG) += objagg.o
 obj-$(CONFIG_PLDMFW) += pldmfw/
 
 # KUnit tests
-obj-$(CONFIG_BITFIELD_KUNIT) += bitfield_kunit.o
+obj-$(CONFIG_BITFIELD_KUNIT_TEST) += bitfield_kunit.o
 obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o
-obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o
-obj-$(CONFIG_BITS_TEST) += test_bits.o
+obj-$(CONFIG_LINEAR_RANGES_KUNIT_TEST) += test_linear_ranges.o
+obj-$(CONFIG_BITS_KUNIT_TEST) += test_bits.o
 obj-$(CONFIG_CMDLINE_KUNIT_TEST) += cmdline_kunit.o
 
 obj-$(CONFIG_GENERIC_LIB_DEVMEM_IS_ALLOWED) += devmem_is_allowed.o

2.30.2

Drop 'S' from end of CONFIG_MPTCP_KUNIT_TESTS inorder to adhear to the KUNIT *_KUNIT_TEST config name format.

---
 net/mptcp/Kconfig  | 2 +-
 net/mptcp/Makefile | 2 +-
 net/mptcp/crypto.c | 2 +-
 net/mptcp/token.c  | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

index a014149aa323..20328920f6ed 100644
@@ -22,7 +22,7 @@ config MPTCP_IPV6
 	depends on IPV6=y
 	default y
 
-config MPTCP_KUNIT_TESTS
+config MPTCP_KUNIT_TEST
 	tristate "This builds the MPTCP KUnit tests" if !KUNIT_ALL_TESTS
 	depends on KUNIT
 	default KUNIT_ALL_TESTS

index a611968be4d7..dcce3cbd1f19 100644
@@ -9,4 +9,4 @@ obj-$(CONFIG_INET_MPTCP_DIAG) += mptcp_diag.o
 
 mptcp_crypto_test-objs := crypto_test.o
 mptcp_token_test-objs := token_test.o
-obj-$(CONFIG_MPTCP_KUNIT_TESTS) += mptcp_crypto_test.o mptcp_token_test.o
+obj-$(CONFIG_MPTCP_KUNIT_TEST) += mptcp_crypto_test.o mptcp_token_test.o

index b472dc149856..a8931349933c 100644
@@ -78,6 +78,6 @@ void mptcp_crypto_hmac_sha(u64 key1, u64 key2, u8 *msg, int len, void *hmac)
 	sha256(input, SHA256_BLOCK_SIZE + SHA256_DIGEST_SIZE, hmac);
 }
 
-#if IS_MODULE(CONFIG_MPTCP_KUNIT_TESTS)
+#if IS_MODULE(CONFIG_MPTCP_KUNIT_TEST)
 EXPORT_SYMBOL_GPL(mptcp_crypto_hmac_sha);
 #endif

index feb4b9ffd462..8f0270a780ce 100644
@@ -402,7 +402,7 @@ void __init mptcp_token_init(void)
 	}
 }
 
-#if IS_MODULE(CONFIG_MPTCP_KUNIT_TESTS)
+#if IS_MODULE(CONFIG_MPTCP_KUNIT_TEST)
 EXPORT_SYMBOL_GPL(mptcp_token_new_request);
 EXPORT_SYMBOL_GPL(mptcp_token_new_connect);
 EXPORT_SYMBOL_GPL(mptcp_token_accept);

2.30.2

Hi Nico,

For MPTCP, we have multiple KUnit tests: crypto and token. That's why we wrote TESTS with a S.

I'm fine without S if we need to stick with KUnit' standard. But maybe the standard wants us to split the two tests and create MPTCP_TOKEN_KUNIT_TEST and MPTCP_TOKEN_KUNIT_TEST config?

In this case, we could eventually keep MPTCP_KUNIT_TESTS which will in charge of selecting the two new ones.

Up to the KUnit maintainers to decide ;-)

Cheers,
Matt

Tessares | Belgium | Hybrid Access Solutions
www.tessares.net

Hi Nico, Matthieu,

Thanks for going to the trouble of making these conform to the KUnit style guidelines.

[Super nitpicky comment for this series: It's 'adhere', not 'adhear'. It's not worth resending this out just to fix the spelling here, but if you do another version, it might be worth fiing.]

So (as this patch series attests), there are a few different config options which cover (or intend one day to cover) multiple suites, and hence end in KUNIT_TESTS. Personally, I'd still slightly prefer TEST here, just to have a common suffix for KUnit test options, and that's what I was going for when writing the style guide.

That being said, it's also worth noting that there is an explicit exemption for existing tests, so if you (for example) have a bunch of automation which relies on this name and can't easily be changed, that's probably more important than a lone 'S'.

This is certainly an option if you want to do it, but personally I wouldn't bother unless it gives you some real advantage. One thing I would note, however, is that it's possible to have a per-subsystem '.kunitconfig' file, so if you want to run a particular group of tests (i.e., have a particular set of config options for testing), it'd be possible to have that rather than a meta-Kconfig entry.

While there are some advantages to trying to have a 1:1 suite:config mapping, there's isn't actually anything that depends on it at the moment (or indeed, anything actively planned). So, in my view, there's no need for you to split the config entry unless you think there's a good reason you'd want to be able to build one set of tests but not the other.

To summarise my view: personally, I'd prefer things the way this patch
works: have everything end in _KUNIT_TEST, even if that enables a couple of suites. The extra 'S' on the end isn't a huge problem if you have a good reason to particularly want to keep it, though: as long as you don't have something like _K_UNIT_VERIFICATION or something equally silly that'd break grepping for '_KUNIT_TEST', it's fine be me.

So, since it matches my prejudices, this patch is:

Thanks,
-- David

Hi David,

Thank you for your very clear reply!

Indeed it makes sense: we don't need to split nor to have a meta-Kconfig entry. We can then remove the extra 'S' and update our tests suite:

I see that the whole series has been marked as "Not Applicable" on Netdev's patchwork:

https://patchwork.kernel.org/project/netdevbpf/patch/0fa191715b236766ad13c5f786d8daf92a9a0cf2.1618388989.git.npache@redhat.com/

Like patch 1/6, I can apply it in MPTCP tree and send it later to net-next with other patches. Except if you guys prefer to apply it in KUnit tree and send it to linux-next?

Cheers,
Matt

Tessares | Belgium | Hybrid Access Solutions
www.tessares.net

Hi Matt,

Given 1/6 is going to net-next, it makes sense to send this out that way too, then, IMHO.
The only slight concern I have is that the m68k test config patch in the series will get split from the others, but that should resolve itself when they pick up the last patch.

At the very least, this shouldn't cause any conflicts with anything we're doing in the KUnit tree.

Cheers,
-- David

Hi David, Nico,

Great!
Mat sent this patch to net-next and David already applied it (thanks!):

https://git.kernel.org/netdev/net-next/c/3fcc8a25e391

I see. I guess for this MPTCP patch, we are fine because MPTCP_KUNIT_TESTS was not used in m68k config.

Thanks for having checked!

Cheers,
Matt

Tessares | Belgium | Hybrid Access Solutions
www.tessares.net

Hi David,

I can apply the m68k test config patch when all other parts have entered mainline. Note that I would have made the same changes myself anyway, on -rc1 defconfig refresh.

Gr{oetje,eeting}s,

Geert

Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

No functional changes other than CONFIG name changes

---
 arch/m68k/configs/amiga_defconfig    | 6 +++---
 arch/m68k/configs/apollo_defconfig   | 6 +++---
 arch/m68k/configs/atari_defconfig    | 6 +++---
 arch/m68k/configs/bvme6000_defconfig | 6 +++---
 arch/m68k/configs/hp300_defconfig    | 6 +++---
 arch/m68k/configs/mac_defconfig      | 6 +++---
 arch/m68k/configs/multi_defconfig    | 6 +++---
 arch/m68k/configs/mvme147_defconfig  | 6 +++---
 arch/m68k/configs/mvme16x_defconfig  | 6 +++---
 arch/m68k/configs/q40_defconfig      | 6 +++---
 arch/m68k/configs/sun3_defconfig     | 6 +++---
 arch/m68k/configs/sun3x_defconfig    | 6 +++---
 12 files changed, 36 insertions(+), 36 deletions(-)

index 786656090c50..77cc4ff7ae3a 100644
@@ -655,11 +655,11 @@ CONFIG_TEST_BLACKHOLE_DEV=m
 CONFIG_FIND_BIT_BENCHMARK=m
 CONFIG_TEST_FIRMWARE=m
 CONFIG_TEST_SYSCTL=m
-CONFIG_BITFIELD_KUNIT=m
+CONFIG_BITFIELD_KUNIT_TEST=m
 CONFIG_RESOURCE_KUNIT_TEST=m
-CONFIG_LINEAR_RANGES_TEST=m
+CONFIG_LINEAR_RANGES_KUNIT_TEST=m
 CONFIG_CMDLINE_KUNIT_TEST=m
-CONFIG_BITS_TEST=m
+CONFIG_BITS_KUNIT_TEST=m
 CONFIG_TEST_UDELAY=m
 CONFIG_TEST_STATIC_KEYS=m
 CONFIG_TEST_KMOD=m

index 9bb12be4a38e..86913bdb265b 100644
@@ -611,11 +611,11 @@ CONFIG_TEST_BLACKHOLE_DEV=m
 CONFIG_FIND_BIT_BENCHMARK=m
 CONFIG_TEST_FIRMWARE=m
 CONFIG_TEST_SYSCTL=m
-CONFIG_BITFIELD_KUNIT=m
+CONFIG_BITFIELD_KUNIT_TEST=m
 CONFIG_RESOURCE_KUNIT_TEST=m
-CONFIG_LINEAR_RANGES_TEST=m
+CONFIG_LINEAR_RANGES_KUNIT_TEST=m
 CONFIG_CMDLINE_KUNIT_TEST=m
-CONFIG_BITS_TEST=m
+CONFIG_BITS_KUNIT_TEST=m
 CONFIG_TEST_UDELAY=m
 CONFIG_TEST_STATIC_KEYS=m
 CONFIG_TEST_KMOD=m

index 413232626d9d..6b5c35e7be44 100644
@@ -633,11 +633,11 @@ CONFIG_TEST_BLACKHOLE_DEV=m
 CONFIG_FIND_BIT_BENCHMARK=m
 CONFIG_TEST_FIRMWARE=m
 CONFIG_TEST_SYSCTL=m
-CONFIG_BITFIELD_KUNIT=m
+CONFIG_BITFIELD_KUNIT_TEST=m
 CONFIG_RESOURCE_KUNIT_TEST=m
-CONFIG_LINEAR_RANGES_TEST=m
+CONFIG_LINEAR_RANGES_KUNIT_TEST=m
 CONFIG_CMDLINE_KUNIT_TEST=m
-CONFIG_BITS_TEST=m
+CONFIG_BITS_KUNIT_TEST=m
 CONFIG_TEST_UDELAY=m
 CONFIG_TEST_STATIC_KEYS=m
 CONFIG_TEST_KMOD=m

index 819cc70b06d8..8fbd238d9d29 100644
@@ -604,11 +604,11 @@ CONFIG_TEST_BLACKHOLE_DEV=m
 CONFIG_FIND_BIT_BENCHMARK=m
 CONFIG_TEST_FIRMWARE=m
 CONFIG_TEST_SYSCTL=m
-CONFIG_BITFIELD_KUNIT=m
+CONFIG_BITFIELD_KUNIT_TEST=m
 CONFIG_RESOURCE_KUNIT_TEST=m
-CONFIG_LINEAR_RANGES_TEST=m
+CONFIG_LINEAR_RANGES_KUNIT_TEST=m
 CONFIG_CMDLINE_KUNIT_TEST=m
-CONFIG_BITS_TEST=m
+CONFIG_BITS_KUNIT_TEST=m
 CONFIG_TEST_UDELAY=m
 CONFIG_TEST_STATIC_KEYS=m
 CONFIG_TEST_KMOD=m

index 8f8d5968713b..dbebbc079611 100644
@@ -613,11 +613,11 @@ CONFIG_TEST_BLACKHOLE_DEV=m
 CONFIG_FIND_BIT_BENCHMARK=m
 CONFIG_TEST_FIRMWARE=m
 CONFIG_TEST_SYSCTL=m
-CONFIG_BITFIELD_KUNIT=m
+CONFIG_BITFIELD_KUNIT_TEST=m
 CONFIG_RESOURCE_KUNIT_TEST=m
-CONFIG_LINEAR_RANGES_TEST=m
+CONFIG_LINEAR_RANGES_KUNIT_TEST=m
 CONFIG_CMDLINE_KUNIT_TEST=m
-CONFIG_BITS_TEST=m
+CONFIG_BITS_KUNIT_TEST=m
 CONFIG_TEST_UDELAY=m
 CONFIG_TEST_STATIC_KEYS=m
 CONFIG_TEST_KMOD=m

index bf15e6c1c939..3ccafd1db067 100644
@@ -636,11 +636,11 @@ CONFIG_TEST_BLACKHOLE_DEV=m
 CONFIG_FIND_BIT_BENCHMARK=m
 CONFIG_TEST_FIRMWARE=m
 CONFIG_TEST_SYSCTL=m
-CONFIG_BITFIELD_KUNIT=m
+CONFIG_BITFIELD_KUNIT_TEST=m
 CONFIG_RESOURCE_KUNIT_TEST=m
-CONFIG_LINEAR_RANGES_TEST=m
+CONFIG_LINEAR_RANGES_KUNIT_TEST=m
 CONFIG_CMDLINE_KUNIT_TEST=m
-CONFIG_BITS_TEST=m
+CONFIG_BITS_KUNIT_TEST=m
 CONFIG_TEST_UDELAY=m
 CONFIG_TEST_STATIC_KEYS=m
 CONFIG_TEST_KMOD=m

index 5466d48fcd9d..572c95f1c8d7 100644
@@ -722,11 +722,11 @@ CONFIG_TEST_BLACKHOLE_DEV=m
 CONFIG_FIND_BIT_BENCHMARK=m
 CONFIG_TEST_FIRMWARE=m
 CONFIG_TEST_SYSCTL=m
-CONFIG_BITFIELD_KUNIT=m
+CONFIG_BITFIELD_KUNIT_TEST=m
 CONFIG_RESOURCE_KUNIT_TEST=m
-CONFIG_LINEAR_RANGES_TEST=m
+CONFIG_LINEAR_RANGES_KUNIT_TEST=m
 CONFIG_CMDLINE_KUNIT_TEST=m
-CONFIG_BITS_TEST=m
+CONFIG_BITS_KUNIT_TEST=m
 CONFIG_TEST_UDELAY=m
 CONFIG_TEST_STATIC_KEYS=m
 CONFIG_TEST_KMOD=m

index 93c305918838..a92d6c4ab9ff 100644
@@ -603,11 +603,11 @@ CONFIG_TEST_BLACKHOLE_DEV=m
 CONFIG_FIND_BIT_BENCHMARK=m
 CONFIG_TEST_FIRMWARE=m
 CONFIG_TEST_SYSCTL=m
-CONFIG_BITFIELD_KUNIT=m
+CONFIG_BITFIELD_KUNIT_TEST=m
 CONFIG_RESOURCE_KUNIT_TEST=m
-CONFIG_LINEAR_RANGES_TEST=m
+CONFIG_LINEAR_RANGES_KUNIT_TEST=m
 CONFIG_CMDLINE_KUNIT_TEST=m
-CONFIG_BITS_TEST=m
+CONFIG_BITS_KUNIT_TEST=m
 CONFIG_TEST_UDELAY=m
 CONFIG_TEST_STATIC_KEYS=m
 CONFIG_TEST_KMOD=m

index cacd6c617f69..e1dbe9208a92 100644
@@ -604,11 +604,11 @@ CONFIG_TEST_BLACKHOLE_DEV=m
 CONFIG_FIND_BIT_BENCHMARK=m
 CONFIG_TEST_FIRMWARE=m
 CONFIG_TEST_SYSCTL=m
-CONFIG_BITFIELD_KUNIT=m
+CONFIG_BITFIELD_KUNIT_TEST=m
 CONFIG_RESOURCE_KUNIT_TEST=m
-CONFIG_LINEAR_RANGES_TEST=m
+CONFIG_LINEAR_RANGES_KUNIT_TEST=m
 CONFIG_CMDLINE_KUNIT_TEST=m
-CONFIG_BITS_TEST=m
+CONFIG_BITS_KUNIT_TEST=m
 CONFIG_TEST_UDELAY=m
 CONFIG_TEST_STATIC_KEYS=m
 CONFIG_TEST_KMOD=m

index 3ae421cb24a4..957aa0277c3c 100644
@@ -622,11 +622,11 @@ CONFIG_TEST_BLACKHOLE_DEV=m
 CONFIG_FIND_BIT_BENCHMARK=m
 CONFIG_TEST_FIRMWARE=m
 CONFIG_TEST_SYSCTL=m
-CONFIG_BITFIELD_KUNIT=m
+CONFIG_BITFIELD_KUNIT_TEST=m
 CONFIG_RESOURCE_KUNIT_TEST=m
-CONFIG_LINEAR_RANGES_TEST=m
+CONFIG_LINEAR_RANGES_KUNIT_TEST=m
 CONFIG_CMDLINE_KUNIT_TEST=m
-CONFIG_BITS_TEST=m
+CONFIG_BITS_KUNIT_TEST=m
 CONFIG_TEST_UDELAY=m
 CONFIG_TEST_STATIC_KEYS=m
 CONFIG_TEST_KMOD=m

index 6da97e28c48e..ebe23c0414fb 100644
@@ -605,11 +605,11 @@ CONFIG_TEST_BLACKHOLE_DEV=m
 CONFIG_FIND_BIT_BENCHMARK=m
 CONFIG_TEST_FIRMWARE=m
 CONFIG_TEST_SYSCTL=m
-CONFIG_BITFIELD_KUNIT=m
+CONFIG_BITFIELD_KUNIT_TEST=m
 CONFIG_RESOURCE_KUNIT_TEST=m
-CONFIG_LINEAR_RANGES_TEST=m
+CONFIG_LINEAR_RANGES_KUNIT_TEST=m
 CONFIG_CMDLINE_KUNIT_TEST=m
-CONFIG_BITS_TEST=m
+CONFIG_BITS_KUNIT_TEST=m
 CONFIG_TEST_UDELAY=m
 CONFIG_TEST_STATIC_KEYS=m
 CONFIG_TEST_KMOD=m

index f54481bb789a..c913aa7635d8 100644
@@ -605,11 +605,11 @@ CONFIG_TEST_BLACKHOLE_DEV=m
 CONFIG_FIND_BIT_BENCHMARK=m
 CONFIG_TEST_FIRMWARE=m
 CONFIG_TEST_SYSCTL=m
-CONFIG_BITFIELD_KUNIT=m
+CONFIG_BITFIELD_KUNIT_TEST=m
 CONFIG_RESOURCE_KUNIT_TEST=m
-CONFIG_LINEAR_RANGES_TEST=m
+CONFIG_LINEAR_RANGES_KUNIT_TEST=m
 CONFIG_CMDLINE_KUNIT_TEST=m
-CONFIG_BITS_TEST=m
+CONFIG_BITS_KUNIT_TEST=m
 CONFIG_TEST_UDELAY=m
 CONFIG_TEST_STATIC_KEYS=m
 CONFIG_TEST_KMOD=m

2.30.2

Applied to

https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/6] kunit: ASoC: topology: adhear to KUNIT formatting standard

      commit: b5fb388da472a69858355560d803602e0ace1006

All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying to this mail.

Thanks,
Mark

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, 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.

Also, "adhear" is not the correct spelling; the correct spelling is "adhere" (from the Latin verb "adhaerere", "to stick", as in "to hold fast or stick by as if by gluing", which then became "to bind oneself to the observance of a set of rules or standards or practices").

- Ted

KUNIT Maintainers, should we go ahead and make this the "standard"?

As Ted has stated...  consistency with 'grep' is my desired outcome.

Whoops... Made that mistake in my v1 and inadvertently copied it over

to all the patches.

Cheers!

-- Nico

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.)

Cheers,
-- David