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

[Steven Rostedt <rostedt@goodmis.org>]

On Fri, 7 Aug 2026 00:17:27 -0700
Song Liu <song@kernel.org> wrote:


> 
> However, requiring compatibility in selftests has its own issues:
> 
> 1) It makes writing and/or maintaining selftests harder. For example,
>    shall the selftest for a new feature fail or skip on older kernels.

Skip. It's a feature of our test suite.

>    Either way, some extra work is required to handle this, e.g.,
>    someone need to remember that this kernel-test combination is
>    expected to fail, and it is OK.

We explicitly require that new features are detectable (sometimes by just
updating /sys/kernel/tracing/README). The ftracetests has a way to see the
dependencies to know if a test should be run or not.

We have a "requires:" field at the top of every test case. For example, in
test.d/filter/event-filter-function.tc:

  #!/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.

> 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.

> 
> 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.

I hope that makes sense.

-- Steve