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@googlegroups.com 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.