On Sat, 25 Feb 2023 at 08:25, David Gow davidgow@google.com wrote:
On Sat, 25 Feb 2023 at 07:23, Linus Torvalds torvalds@linux-foundation.org wrote:
On Tue, Feb 21, 2023 at 5:51 PM Shuah Khan skhan@linuxfoundation.org wrote:
This KUnit update for Linux 6.3-rc1 consists of cleanups, new features, and documentation updates:
Hmm. I have not actually bisected this or tried to otherwise figure out exactly what is wrong, but the kunit code ends up being really annoying for my build testing.
This will be due to 7170b7ed6acb ("kunit: Add "hooks" to call into KUnit when it's built as a module").
The "hooks.o" file is special in that it needs to be built-in even when the other KUnit files are built as a module, and clearly the kbuild hackery for that has fallen apart.
In particular, if I do
makerepeatedly - ie with no other changes in between - the kunit code ends up re-building itself for no apparent reason.
Which then causes a re-link and makes it all really slow.
Maybe I'm barking up the wrong tree, but just do
make allmodconfig
and then do two plain "make"s in succession (feel free to add "-jXYZ" to make it go much faster ;).
The second build - that shouldn't have to re-build anything - still does this:
CALL scripts/checksyscalls.sh DESCEND objtool CHK kernel/kheaders_data.tar.xz CC lib/kunit/hooks.o AR lib/built-in.a CC lib/kunit/hooks.o AR lib/kunit/lib.a AR built-in.a AR vmlinux.a LD vmlinux.o ...
and it all takes much longer than an empty kernel build _should_ take.
As best I can tell, this is kbuild getting very confused by the way we're adding lib/kunit/hooks.o directly in lib/Makefile (rather than going through lib/kunit/Makefile).
Moving lib/kunit/hooks.c -> lib/kunit_hooks.c and adjusting the makefile to match _seems_ to fix it here:
diff --git a/lib/Makefile b/lib/Makefile index 469be6240523..bb87df427cff 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -131,10 +131,8 @@ obj-$(CONFIG_KUNIT) += kunit/ # Include the KUnit hooks unconditionally. They'll compile to nothing if # CONFIG_KUNIT=n, otherwise will be a small table of static data (static key, # function pointers) which need to be built-in even when KUnit is a module. -ifeq ($(CONFIG_KUNIT), m) -obj-y += kunit/hooks.o -else -obj-$(CONFIG_KUNIT) += kunit/hooks.o +ifdef CONFIG_KUNIT +obj-y += kunit_hooks.o endif
Splitting the KUnit code up like that is a little bit ugly, so I'm open to any suggestions of how better to structure it.
Regardless, I'll play around a bit and see if I can come up with anything better before sending that out.
I managed to get it working by always recursing into the kunit/ directory with obj-y, which is cleaner. So this patch should fix it: https://lore.kernel.org/linux-kselftest/20230225014529.2259752-1-davidgow@go...
Sorry again, -- David