From mboxrd@z Thu Jan 1 00:00:00 1970 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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 14A4BE92734 for ; Mon, 29 Dec 2025 16:41:47 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 818E310E391; Mon, 29 Dec 2025 16:41:47 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="BIDPe0Hw"; dkim-atps=neutral Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by gabe.freedesktop.org (Postfix) with ESMTPS id 8206110E391; Mon, 29 Dec 2025 16:41:46 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 5BF9160052; Mon, 29 Dec 2025 16:41:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 74E71C4CEF7; Mon, 29 Dec 2025 16:41:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1767026505; bh=fcoV0QeqQ+GG4ebz8LT6JHQhUB85r9DPN/+bdPdWAaI=; h=Date:Subject:Cc:To:From:References:In-Reply-To:From; b=BIDPe0HwRNB5xB8QtYWNvfu0UyoqcIfsl5zQ05a3OTWPhdpXGd3ivMoz6kF2NDx/6 P9tVlWKLNp9/Cw3/fg+WDuU+W+kkDsHZuweSVmiYrlDe1ENVxzSRO5xKMYvmpKXOZe +sblb1DuN7gHVp3oCu79PF58avpDtHPWfqC0hdVSPxLviLAYb6xBrSdrIvh7Eh3yve w/2XkvYhGVJR0hruy0WOBclsZbZFYHw3xy+zNKIH0a56l7yDWrDWTBFkcU4jhmadP+ UOpXp82He2BRbNdRkQ4B4LlRA6skEUxVF9xordWGW0qHYKaXPmVQjfMFYIFXKXP7VH OWCp64owuie9Q== Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 29 Dec 2025 17:41:38 +0100 Message-Id: Subject: Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h Cc: "Andrew Morton" , "Yury Norov (NVIDIA)" , "Masami Hiramatsu" , "Mathieu Desnoyers" , "Andy Shevchenko" , "Christophe Leroy" , "Randy Dunlap" , "Ingo Molnar" , "Jani Nikula" , "Joonas Lahtinen" , "David Laight" , "Petr Pavlu" , "Andi Shyti" , "Rodrigo Vivi" , "Tvrtko Ursulin" , "Daniel Gomez" , "Greg Kroah-Hartman" , "Rafael J. Wysocki" , , , , , To: "Steven Rostedt" From: "Danilo Krummrich" References: <20251225170930.1151781-1-yury.norov@gmail.com> <20251225170930.1151781-8-yury.norov@gmail.com> <20251226115848.298465d4@gandalf.local.home> <20251228133150.1d5731d04bc1b685b0fe81c1@linux-foundation.org> <20251229111748.3ba66311@gandalf.local.home> In-Reply-To: <20251229111748.3ba66311@gandalf.local.home> X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Mon Dec 29, 2025 at 5:17 PM CET, Steven Rostedt wrote: > It will waste a lot of kernel developers time. Go to conferences and talk > with developers. trace_printk() is now one of the most common ways to deb= ug > your code. Having to add "#include " in every file > that you use trace_printk() (and after your build fails because you forgo= t > to include that file **WILL** slow down kernel debugging for hundreds of > developers! It *is* used more than printk() for debugging today. Because > it's fast and can be used in any context (NMI, interrupt handlers, etc). I strongly agree with this. I heavly use trace_printk() for debugging for a= long time and have recommended it to dozens of people that all have been very thankful for it -- especially when it comes to debugging race conditions on= a tough timing, where a normal printk() simply "fixes" the race. Having to include additional headers would be very painful, especially when debugging large code bases with lots of files. For instance, one of the components I maintain is the nouveau driver with 773 C files and 1390 files overall. I suppose it would be fair to argue that such codebases usually have their = own common header files that could be reused, but even in that case, I=E2=80=99= d consider the ergonomic cost too high. - Danilo