From: Tzung-Bi Shih <tzungbi@kernel.org>
To: Daniel Latypov <dlatypov@google.com>
Cc: bleung@chromium.org, brendan.higgins@linux.dev,
davidgow@google.com, rmoar@google.com, rostedt@goodmis.org,
mhiramat@kernel.org, naveen@kernel.org,
anil.s.keshavamurthy@intel.com, davem@davemloft.net,
chrome-platform@lists.linux.dev, linux-kselftest@vger.kernel.org,
kunit-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/7] platform/chrome: Add Kunit tests for protocol device drivers
Date: Tue, 1 Jul 2025 12:20:13 +0000 [thread overview]
Message-ID: <aGPSfaC1AohSV3_H@google.com> (raw)
In-Reply-To: <CAGS_qxpqQ1Z5QOxmXoXQyFBygdfW+1R=g9f=bbJo54Ex8LA7Kw@mail.gmail.com>
On Tue, Jul 01, 2025 at 02:22:40PM +0900, Daniel Latypov wrote:
> On Mon, Jun 30, 2025 at 3:32 PM Tzung-Bi Shih <tzungbi@kernel.org> wrote:
> > On Tue, May 20, 2025 at 09:04:53AM -0700, Daniel Latypov wrote:
> > > You mention you don't like how static stubs requires modifying the
> > > code-under-test.
> > > Since it gets eliminated by the preprocessor unless you're compiling
> > > for KUnit, is the concern more so about how it conceptually feels
> > > wrong to do so?
> > > For the Android GKI kernel, they have (or had) KUnit enabled so there
> > > is potentially concern about real runtime cost there, not sure if you
> > > have something similar in mind.
> >
> > Not exactly. Ideally, I think we shouldn't modify the CUT. I'm wondering
> > if there is a way to not change the CUT but also break the external
> > dependencies.
> >
> > > But stepping back, ftrace_stubs technically require modifying the code
> > > to make sure funcs are marked as `noinline`, which this patch series
> > > does not do.
> ...
> > They could be partially inlined even though they are exported symbols.
>
> So to summarize, right now we're stuck with having to modify the code.
> (Unless someone can come up with something really clever, but not too clever)
>
> To make it concrete, the current approach would look like:
>
> int func(char* arg1, int arg2) {
> KUNIT_STATIC_STUB_REDIRECT(func, arg1, arg2);
> ... // unchanged
> }
>
> vs an ftrace/kprobe approach that needs a conditional `noinline`
>
> KUNIT_STUBBABLE int func(char* arg1, int arg2) {
> ... // unchanged
> }
>
> The latter is definitely simpler and less burdensome.
> But I don't know if it's simpler enough to warrant a second
> implementation existing for me personally.
Instead of KUNIT_STUBBABLE macros, I was thinking of:
diff --git a/Makefile b/Makefile
index 35e6e5240c61..40319083f58b 100644
--- a/Makefile
+++ b/Makefile
@@ -979,6 +979,10 @@ ifdef CONFIG_DEBUG_SECTION_MISMATCH
KBUILD_CFLAGS += -fno-inline-functions-called-once
endif
+ifdef CONFIG_KUNIT_KPROBE_STUBS
+KBUILD_CFLAGS += -fno-inline
+endif
+
# `rustc`'s `-Zfunction-sections` applies to data too (as of 1.59.0).
ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION
KBUILD_CFLAGS_KERNEL += -ffunction-sections -fdata-sections
I don't know what are most people's usages. I always run KUnit tests in qemu
or at least in some real devices that I less care about the performance.
Thus, turning inline off globally in such environments is totally acceptable.
prev parent reply other threads:[~2025-07-01 12:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-20 8:24 [RFC PATCH 0/7] platform/chrome: Add Kunit tests for protocol device drivers Tzung-Bi Shih
2025-05-20 8:24 ` [RFC PATCH 1/7] kunit: expose ftrace-based API for stubbing out functions during tests Tzung-Bi Shih
2025-05-20 8:24 ` [RFC PATCH 2/7] platform/chrome: kunit: cros_ec_i2c: Add tests with ftrace stub Tzung-Bi Shih
2025-05-20 8:24 ` [RFC PATCH 3/7] platform/chrome: kunit: cros_ec_i2c: Use static stub instead Tzung-Bi Shih
2025-05-20 8:24 ` [RFC PATCH 4/7] platform/chrome: kunit: cros_ec_spi: Add tests with ftrace stub Tzung-Bi Shih
2025-05-20 8:24 ` [RFC PATCH 5/7] platform/chrome: kunit: cros_ec_spi: Call .probe() directly Tzung-Bi Shih
2025-05-20 8:24 ` [RFC PATCH 6/7] kunit: Expose 'kprobes stub' API to redirect functions Tzung-Bi Shih
2025-05-20 8:24 ` [RFC PATCH 7/7] platform/chrome: kunit: cros_ec_spi: Use kprobes stub instead Tzung-Bi Shih
2025-05-20 16:04 ` [RFC PATCH 0/7] platform/chrome: Add Kunit tests for protocol device drivers Daniel Latypov
2025-06-30 6:32 ` Tzung-Bi Shih
2025-07-01 5:22 ` Daniel Latypov
2025-07-01 12:20 ` Tzung-Bi Shih [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aGPSfaC1AohSV3_H@google.com \
--to=tzungbi@kernel.org \
--cc=anil.s.keshavamurthy@intel.com \
--cc=bleung@chromium.org \
--cc=brendan.higgins@linux.dev \
--cc=chrome-platform@lists.linux.dev \
--cc=davem@davemloft.net \
--cc=davidgow@google.com \
--cc=dlatypov@google.com \
--cc=kunit-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=naveen@kernel.org \
--cc=rmoar@google.com \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.