[linux-kselftest-test,2/3] kunit: allow kunit to be loaded as a module
diff mbox series

Message ID 1570545832-32326-3-git-send-email-alan.maguire@oracle.com
State New
Headers show
Series
  • kunit: support module-based build
Related show

Commit Message

Alan Maguire Oct. 8, 2019, 2:43 p.m. UTC
Making kunit itself buildable as a module allows for "always-on"
kunit configuration; specifying CONFIG_KUNIT=m means the module
is built but only used when loaded.  Kunit test modules will load
kunit.ko as an implicit dependency, so simply running
"modprobe my-kunit-tests" will load the tests along with the kunit
module and run them.

Signed-off-by: Knut Omang <knut.omang@oracle.com>
Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
---
 kunit/Kconfig  | 2 +-
 kunit/Makefile | 9 +++++++++
 kunit/test.c   | 4 ++++
 3 files changed, 14 insertions(+), 1 deletion(-)

Comments

Andy Shevchenko Oct. 8, 2019, 2:55 p.m. UTC | #1
On Tue, Oct 08, 2019 at 03:43:51PM +0100, Alan Maguire wrote:
> Making kunit itself buildable as a module allows for "always-on"
> kunit configuration; specifying CONFIG_KUNIT=m means the module
> is built but only used when loaded.  Kunit test modules will load
> kunit.ko as an implicit dependency, so simply running
> "modprobe my-kunit-tests" will load the tests along with the kunit
> module and run them.

> +#ifdef MODULE

> +#endif /* MODULE */

This is strange. Why do you need ifdef?
Alan Maguire Oct. 8, 2019, 3:15 p.m. UTC | #2
On Tue, 8 Oct 2019, Andy Shevchenko wrote:

> On Tue, Oct 08, 2019 at 03:43:51PM +0100, Alan Maguire wrote:
> > Making kunit itself buildable as a module allows for "always-on"
> > kunit configuration; specifying CONFIG_KUNIT=m means the module
> > is built but only used when loaded.  Kunit test modules will load
> > kunit.ko as an implicit dependency, so simply running
> > "modprobe my-kunit-tests" will load the tests along with the kunit
> > module and run them.
> 
> > +#ifdef MODULE
> 
> > +#endif /* MODULE */
> 
> This is strange. Why do you need ifdef?
>

Ah, this was an incorrect assumption on my part; I thought that
declaring a module license for built-in code might trigger a warning 
during build. I'll remove the #ifdef MODULE around licenses in v3 (v2 has 
already gone out as I mistakenly initially sent the wrong version of the 
patches). I've verified that removing it triggers no warnings.

Thanks to you and Randy for spotting this!

Alan

> -- 
> With Best Regards,
> Andy Shevchenko
> 
> 
>

Patch
diff mbox series

diff --git a/kunit/Kconfig b/kunit/Kconfig
index f28bf086..d84f480 100644
--- a/kunit/Kconfig
+++ b/kunit/Kconfig
@@ -5,7 +5,7 @@ 
 menu "KUnit support"
 
 config KUNIT
-	bool "Enable support for unit tests (KUnit)"
+	tristate "Enable support for unit tests (KUnit)"
 	help
 	  Enables support for kernel unit tests (KUnit), a lightweight unit
 	  testing and mocking framework for the Linux kernel. These tests are
diff --git a/kunit/Makefile b/kunit/Makefile
index 769d940..932a3f2 100644
--- a/kunit/Makefile
+++ b/kunit/Makefile
@@ -1,7 +1,16 @@ 
+ifeq ($(CONFIG_KUNIT),m)
+obj-$(CONFIG_KUNIT) +=			kunit.o
+
+kunit-objs +=				test.o \
+					string-stream.o \
+					assert.o \
+					try-catch.o
+else
 obj-$(CONFIG_KUNIT) +=			test.o \
 					string-stream.o \
 					assert.o \
 					try-catch.o
+endif
 
 obj-$(CONFIG_KUNIT_TEST) +=		test-test.o \
 					string-stream-test.o
diff --git a/kunit/test.c b/kunit/test.c
index e7896f1..6024627 100644
--- a/kunit/test.c
+++ b/kunit/test.c
@@ -484,3 +484,7 @@  void kunit_cleanup(struct kunit *test)
 	}
 }
 EXPORT_SYMBOL_GPL(kunit_cleanup);
+
+#ifdef MODULE
+MODULE_LICENSE("GPL");
+#endif /* MODULE */