Re: [RFC PATCH bpf-next v3 2/2] selftests/livepatch: update test-ftrace.sh for deprecated ftrace_enabled

Hi Steven,

Thanks for sharing your experience!

On Fri, Aug 7, 2026 at 5:43 AM Steven Rostedt <[email protected]> wrote:
>
> On Fri, 7 Aug 2026 00:17:27 -0700
> Song Liu <[email protected]> wrote:
[...]
>   #!/bin/sh
>   # SPDX-License-Identifier: GPL-2.0
>   # description: event filter function - test event filtering on functions
>   # requires: set_event events/kmem/kmem_cache_free/filter
>   # flags: instance
>
> If "set_event" or "events/kmem/kmem_cache_free/filter" does not exist, the
> test will be skipped.

Hmm.. If a bug somehow causes set_event to disappear, this test will
be skipped by accident, no? These types of bugs are not common
though.

>
> > 2) It delays the actual deprecation of a feature. IOW, the feature will
> >    somehow stays in the selftests for much longer time.
>
> We do not deprecate features. tracefs code is user API. We do not break
> user space. The ftrace_enabled is something that is being removed because
> it is broken to begin with. In fact, if we find out that anything depends
> on ftrace_enabled, we need to revert the change that disabled it.
>
> The removal of ftrace_enabled is the exception and not the rule.

Agreed that ftrace APIs need to be very stable, as there are many out
of tree users. OTOH, I think livepatch can afford breaking some
compatibility.

> > Overall, I think requiring backward compatibility appears to be
> > attractive when we go from "having very little selftests" to
> > "having some selftest coverage". However, not requiring backward
> > compatibility will help us achieve better test coverage in the long run.
>
> The ftrace selftest requirements are different than the BPF requirements.
> We have been supporting this since 2014 without issue. And have actually
> found making things backward compatible helpful. We are not going to change
> that.

With mature selftests, I guess testing LTS kernels with the selftests shipped
with them is still a valid option? I guess this is up to the folks who run these
tests.

In this specific case, given the logic is not that complex, I agree we can
maintain the compatibility,

Thanks,
Song