On Thu, Feb 2, 2023 at 6:37 PM Florent Revest <revest@xxxxxxxxxxxx> wrote: > > On Thu, Feb 2, 2023 at 4:02 PM Mark Rutland <mark.rutland@xxxxxxx> wrote: > > Looking at samples/ftrace/, as of this patch we have a few samples that are > > almost identical, modulo the function being traced, and some different register > > shuffling for arguments: > > > > * ftrace-direct.c and ftrace-direct-multi.c > > * ftrace-direct-modify.c and ftrace-direct-modify > > > > ... perhaps it would be better to just delete the !multi versions ? > > The multi versions hook two functions and the !multi hook just one but > I agree that this granularity in coverage is probably just a > maintenance burden and doesn't help with much! :) > I'll delete the !multi in v2, as part of the patch 2 and patch 1 will > just migrate the selftest to use the multi API. Actually, I'm not sure anymore if we should delete the !multi samples... I realized that they are also used as part of the ftrace selftests in: - tools/testing/selftests/ftrace/test.d/direct/ftrace-direct.tc - tools/testing/selftests/ftrace/test.d/direct/kprobe-direct.tc It does not really make sense to use the ftrace-direct-muti sample as a drop-in replacement for the ftrace-direct sample there since they don't really do the same thing so we would either need to change the test a bit or the multi sample. Also, we would still need to adapt the ftrace-direct-too sample since it has no multi equivalent and is required there. It's certainly doable but now it feels to me like going one step too far with the refactoring within the scope of this series. Do you think it's worth it ? I have 70% of that work done already so I'm happy to finish it but I thought I should check back before sending a v2 that's more complex than anticipated.