Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CDA06C636D7 for ; Tue, 31 Jan 2023 19:50:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231479AbjAaTu4 (ORCPT ); Tue, 31 Jan 2023 14:50:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54180 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230522AbjAaTuy (ORCPT ); Tue, 31 Jan 2023 14:50:54 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 31FD7530C8; Tue, 31 Jan 2023 11:50:53 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id C1A8B616C2; Tue, 31 Jan 2023 19:50:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3C923C433EF; Tue, 31 Jan 2023 19:50:50 +0000 (UTC) Date: Tue, 31 Jan 2023 14:50:48 -0500 From: Steven Rostedt To: Alexei Starovoitov Cc: Ross Zwisler , LKML , Ross Zwisler , Andrii Nakryiko , linux-trace-kernel@vger.kernel.org, Mykola Lysenko , Alexei Starovoitov , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Shuah Khan , bpf , "open list:KERNEL SELFTEST FRAMEWORK" Subject: Re: [PATCH 3/9] selftests/bpf: use canonical ftrace path Message-ID: <20230131145048.6fac87d3@gandalf.local.home> In-Reply-To: <20230131005315.phdnhkeeconxxm3e@macbook-pro-6.dhcp.thefacebook.com> References: <20230130181915.1113313-1-zwisler@google.com> <20230130181915.1113313-4-zwisler@google.com> <20230130145932.37cf6b73@gandalf.local.home> <20230130183419.0626dc21@gandalf.local.home> <20230131005315.phdnhkeeconxxm3e@macbook-pro-6.dhcp.thefacebook.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 30 Jan 2023 16:53:15 -0800 Alexei Starovoitov 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