Re: [RFC PATCH 0/7] platform/chrome: Add Kunit tests for protocol device drivers

[Tzung-Bi Shih]

On Tue, May 20, 2025 at 09:04:53AM -0700, Daniel Latypov wrote:
> On Tue, May 20, 2025 at 1:25 AM 'Tzung-Bi Shih' via KUnit Development
> <kunit-dev@xxxxxxxxxxxxxxxx> wrote:
> > [...]
> > Questions:
> > - Are we going to support ftrace stub so that tests can use it?
> >
> > - If ftrace stub isn't on the plate (e.g. due to too many dependencies), how
> >   about the kprobes stub?  Is it something we could pursue?
> 
> Quick comment,
> If I recall, the thought process was that we could consider it in the
> future if there was enough demand for it.

Sorry for the late reply. I was doing some more experiments and stuck by
some else.

> We have these drawbacks with the current ftrace stubs:
> * doesn't compile on all arches
> * silently doesn't work on inlined functions <== scariest one to me

I see. I did some experiments and realized that kprobe stubs also share
the same concern. Thus I'm wondering if there is a way that kprobe stub
detects the redirection may fail, at least it can skip the test case
(e.g. register_kprobe() returns -ENOENT when it can't find the symbol
via kprobe_lookup_name()). But it seems no way if the target function
is partially inlined.

> 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.
> I've not looked at cros_ec_{un,}register() to check if they're at risk
> of inlining, but wanted to call that out, that ftrace stubs
> technically don't handle your usage pattern 100% properly.

True. They could be partially inlined even though they are exported symbols.