From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C906E221F39 for ; Sun, 21 Jun 2026 21:19:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=216.40.44.15 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782076762; cv=none; b=nY25u2zDBXpNqtEyZOazPhZtTOycAmlKrpFmTw72MJFMor8SUNFM0I7aONzparPWf19zYk757KMjVnCFM5WZ8KVA5Db/0qXfrvk4O6tM0e3MwReWWFFjf9psaf3PvH5d9JURDADqvIb3ZmIRkF7ROWjEYupZnEwf7KKxUaYCDZc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782076762; c=relaxed/simple; bh=DzTZgwg+7jyN40vvJrHGtYdbX2uWYxwUOfVYX8gBVdI=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=impNM62ysCtr69m+qVOBHl/6Z4d0Nvl8gYYBHTssRx0ub9/Uwt2J3WTxjHyWqtOAgb+kbZixaMHOHq5ZjA9IHsSDIMEXq96ZEjR93IlP5V032TSNPxqD03RQNCaNTyTwZyRi/LNCOgZZlw4bYna0SU3fToRJpdtQlMcJzlgTEpE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=goodmis.org; spf=pass smtp.mailfrom=goodmis.org; arc=none smtp.client-ip=216.40.44.15 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=goodmis.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=goodmis.org Received: from omf05.hostedemail.com (lb01a-stub [10.200.18.249]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 2BEF71A0506; Sun, 21 Jun 2026 21:19:18 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: rostedt@goodmis.org) by omf05.hostedemail.com (Postfix) with ESMTPA id 0DE9A20011; Sun, 21 Jun 2026 21:19:12 +0000 (UTC) Date: Sun, 21 Jun 2026 17:19:10 -0400 From: Steven Rostedt To: Linus Torvalds Cc: Agatha Isabelle Moreira , Yury Norov , LKML , Masami Hiramatsu , Mathieu Desnoyers , Ao Sun , David Carlier , Karl Mehltretter , Martin Kaiser , Pengpeng Hou , Qian-Yu Lin , Rik van Riel , Rosen Penev , Shuvam Pandey , Vineeth Pillai , Yash Suthar , Yu Peng Subject: Re: [GIT PULL] tracing: Updates for 7.2 Message-ID: <20260621171910.3d1f6504@fedora> In-Reply-To: References: <20260616180122.57a3b426@fedora> <20260619081513.3e4a1fb0@fedora> <20260619115427.3f68a1e8@fedora> X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 0DE9A20011 X-Stat-Signature: 5in7kyane1o6jgzbqut6qf3etd9w7tz4 X-Rspamd-Server: rspamout08 X-Session-Marker: 726F737465647440676F6F646D69732E6F7267 X-Session-ID: U2FsdGVkX1/LGFOuTiilsD5+OlpCUiE6mSlQOEyE7zA= X-HE-Tag: 1782076752-356624 X-HE-Meta: U2FsdGVkX1/P/KXZyxvlXmFdMa7BmTTARbHHL7lOS+g5Al1A7wfxbXseOT7S5kkpBrhDbAl7bP/htXhjEQp91XNGWsY0Q6i4JiBmiGXSky1V7MnXWapoTe9EIFJnoRf4SaSEjbgbG3qlWxWrbZI8U1enlUxG0XwZ0+Uu1BuCXRYE+8gItNuyxJ0Jo2tv/dxHEjr9xkIyLLP/w0ALzJRpz9HRBev1pJME6NEFP4O79pxOcJDNpmdGpz/afksjBiUz4inZzWkh3P3Hn6Bb1ii30fCEH6h1KsHz+uAXGRnRd4XnFNgrC4ZO4WCJEXX8YLnK0Z1/+Idci61BK1w1atc/S1coYQuxhxcSnp8apu+/Fhdifsq8hAwNKXXB/+o3pxk/ On Sun, 21 Jun 2026 13:51:30 -0700 Linus Torvalds wrote: > > First you say that it's for a debugging patch that adds the > trace_printk() locally and never makes it into the tree, which > explains why nobody else wants to see that thing. Who is that nobody? I know you don't use trace_printk() at all, but I would love to have a survey of *all* kernel developers to find out the percentage that find it useful. You seem to be of the mind set "I don't think it's useful, so nobody should think it's useful". Just like you did with Link tags that point to patches. > > And now you say the problem is that you have to remember to not commit > the header you added. It's not the main problem, it's just one of many things that can happen. But yeah, it's not a big deal. > > JUST LIKE THAT WHOLE trace_printk() that was apparently all just local > and never committed either. There's been cases of trace_printk() ending up accidentally in production. The reason to not allow it in production is because it writes to the main tracing buffer and it's always on. If it was allowed, every subsystem would use it and then when you want to debug something you have to fight the noise of everyone else's trace_printk() when you want to see yours. It would also make trace events useless. Thus, a common workflow (and this is what others have told me they do, I personally don't do this) is to use trace_printk() to find out what is useful to track for debugging. Then, if important data was traced, they would turn it into a trace_event. Trace events are basically trace_printk()s but in a proper form. On my Fedora laptop: $ sudo cat /sys/kernel/tracing/available_events | wc -l 2719 Thus trace_events are very commonly used, which are just trace_printk()s that you can individually enable and disable. > > So in your magical world, adding the trace_printk() isn't a problem. > Spending effort debugging things that are hard to reproduce isn't a > problem. And remembering to not commit said debug code is apparently > also a non-issue. > > But that extra #include is suddenly a huge problem both to add in the > first place - oh woe, how it hurts to add that one line to make it > possible to do those week-long debug sessions - and then to not > commit. It is just frustrating when you are focusing on debugging something, and you go to compile and it errors with "prototype not found". It's just one more thing added to frustration of fixing code that doesn't work. I thought we want to make developers lives easier. But since *you* don't use it, you think it's not an issue. > > This thread has gone from just plain dumb to ridiculous, and I have to > mute this conversation in order to not get dumber by association. I 100% agree with getting rid of things in kernel.h. But the little Makefile change and the config can keep people using trace_printk() like they have been doing since 2009. Would you at least be OK with that? It shouldn't make any difference to your workflow, but would make things easier for others, even if you don't think it would. At least humor us ;-) -- Steve