On Mon, 30 Jan 2023 16:53:15 -0800 Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > I don't think /sys/kernel/debug/tracing can ever be deprecated. > There are plenty of user space applications (not bpf related at all) that > expect it to be in that location. > > Quick search shows: > > android profiler: > https://android.googlesource.com/platform/external/perfetto/+/refs/heads/master/src/tools/dump_ftrace_stats/main.cc#60 > > java profiler: > https://github.com/jvm-profiling-tools/async-profiler/blob/master/src/perfEvents_linux.cpp#L85 These can easily be changed. We have deprecated stuff in the past, by making sure all the affected code is updated properly. One way is to start adding printks when used. Then update to WARN() to get people to complain. Yes, the burden is on us (me and others) to go out and fix the issues. But it is possible to do, as I've done it before. > > > If anything, leaving hardcoded calls like that forces the user to mount > > debugfs when they may not want to. The entire point of tracefs was to allow > > users to have access to the trace events without having to expose debugfs > > and all the crud it brings with it. This was requested several times before > > it was added. > > All makes sense. > > > What is your technical reason for not modifying the code to look for > > tracefs in /sys/kernel/tracing and if it's not there try > > /sys/kernel/debug/tracing, and if both are not found, try mounting it. > > libbpf already has code to probe both locations. > The point that full deprecation of /sys/kernel/debug/tracing is not possible, > hence no point doing the diff: > 48 files changed, 96 insertions(+), 95 deletions(-) > It doesn't move the needle. Just a code churn. As code in the Linux kernel is used as examples for future work, it should not be using an interface that is obsolete. That's enough rational for code churn. This "we can never deprecated so we won't even try" BS is not an answer. -- Steve
