[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABVgOSnqZAuWZJpER4B_hPHorj3DZSpv+ygudC-wSVZ5-o14uQ@mail.gmail.com>
Date: Sat, 25 Feb 2023 08:25:11 +0800
From: David Gow <davidgow@...gle.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Shuah Khan <skhan@...uxfoundation.org>, shuah <shuah@...nel.org>,
Brendan Higgins <brendanhiggins@...gle.com>,
linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] KUnit next update for Linux 6.3-rc1
On Sat, 25 Feb 2023 at 07:23, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Tue, Feb 21, 2023 at 5:51 PM Shuah Khan <skhan@...uxfoundation.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
>
> make
>
> repeatedly - 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.
Sorry for the inconvenience!
-- David
Download attachment "smime.p7s" of type "application/pkcs7-signature" (4003 bytes)
Powered by blists - more mailing lists