On Fri, 7 Aug 2026 00:17:27 -0700 Song Liu <[email protected]> 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
