[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fb2a41b2-a872-4fcd-8a97-df3a946c6a81@suse.com>
Date: Tue, 17 Jun 2025 09:44:49 +0200
From: Petr Pavlu <petr.pavlu@...e.com>
To: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
Cc: Luis Chamberlain <mcgrof@...nel.org>,
Sami Tolvanen <samitolvanen@...gle.com>, Daniel Gomez
<da.gomez@...sung.com>, Brendan Higgins <brendan.higgins@...ux.dev>,
David Gow <davidgow@...gle.com>, Rae Moar <rmoar@...gle.com>,
linux-modules@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-kselftest@...r.kernel.org, kunit-dev@...glegroups.com
Subject: Re: [PATCH 3/3] kunit: test: Drop CONFIG_MODULE ifdeffery
On 6/12/25 4:53 PM, Thomas Weißschuh wrote:
> The function stubs exposed by module.h allow the code to compile properly
> without the ifdeffery. The generated object code stays the same, as the
> compiler can optimize away all the dead code.
> As the code is still typechecked developer errors can be detected faster.
>
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
I'm worried that patches #2 and #3 make the code harder to understand
because they hide what is compiled and when.
Normally, '#ifdef CONFIG_XYZ' or IS_ENABLED(CONFIG_XYZ) directly
surrounds functionality that should be conditional. This makes it clear
what is used and when.
The patches obscure whether, for instance, kunit_module_notify() in
lib/kunit/test.c is actually used and present in the resulting binary
behind several steps. Understanding its usage requires tracing the code
from kunit_module_notify() to the definition of kunit_mod_nb, then to
the register_module_notifier() call, and finally depends on an ifdef in
another file, include/linux/module.h.
Is this really better? Are there places where this pattern is already
used? Does it actually help in practice, considering that CONFIG_MODULES
is enabled in most cases?
--
Thanks,
Petr
Powered by blists - more mailing lists