From: Jani Nikula <jani.nikula@linux.intel.com>
To: Yury Norov <yury.norov@gmail.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Joel Fernandes <joelagnelf@nvidia.com>,
Steven Rostedt <rostedt@goodmis.org>,
Andrew Morton <akpm@linux-foundation.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Christophe Leroy <chleroy@kernel.org>,
Randy Dunlap <rdunlap@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
David Laight <david.laight@runbox.com>,
Petr Pavlu <petr.pavlu@suse.com>,
Andi Shyti <andi.shyti@kernel.org>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Tvrtko Ursulin <tursulin@ursulin.net>,
Daniel Gomez <da.gomez@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Danilo Krummrich <dakr@kernel.org>,
linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, linux-modules@vger.kernel.org,
linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
Date: Mon, 05 Jan 2026 20:30:54 +0200 [thread overview]
Message-ID: <7df7c705c02cae6d609a3bc5f153082cf0658a60@intel.com> (raw)
In-Reply-To: <aVvoe5fQN3EUtEAJ@yury>
On Mon, 05 Jan 2026, Yury Norov <yury.norov@gmail.com> wrote:
> On Mon, Jan 05, 2026 at 11:29:51AM +0200, Jani Nikula wrote:
>> On Sat, 03 Jan 2026, Yury Norov <yury.norov@gmail.com> wrote:
>> > On Sat, Jan 03, 2026 at 02:57:58PM +0200, Andy Shevchenko wrote:
>> >> On Fri, Jan 02, 2026 at 07:50:59PM -0500, Joel Fernandes wrote:
>> >> > On Mon, Dec 29, 2025 at 11:17:48AM -0500, Steven Rostedt wrote:
>> >>
>> >> ...
>> >>
>> >> > I use trace_printk() all the time for kernel, particularly RCU development.
>> >> > One of the key usecases I have is dumping traces on panic (with panic on warn
>> >> > and stop tracing on warn enabled). This is extremely useful since I can add
>> >> > custom tracing and dump traces when rare conditions occur. I fixed several
>> >> > bugs with this technique.
>> >> >
>> >> > I also recommend keeping it convenient to use.
>> >>
>> >> Okay, you know C, please share your opinion what header is the best to hold the
>> >> trace_printk.h to be included.
>> >
>> > What if we include it on Makefile level, similarly to how W=1 works?
>> >
>> > make D=1 // trace_printk() is available
>> > make D=0 // trace_printk() is not available
>> > make // trace_printk() is not available
>> >
>> > Where D stands for debugging.
>> >
>> > D=1 may be a default setting if you prefer, but the most important is
>> > that every compilation unit will have an access to debugging without
>> > polluting core headers.
>>
>> You do realize this means recompiling everything when adding D=1 for
>> debugging?
>
> Yes sir I do.
>
> It would be as simple (or hard) as building another arch:
>
> make O=../build/linux-arm64
> make O=../build/linux-x86_64
> make D=1 W=1 O=../build/linux-x86_64-dev
>
> If you're both developer and CI engineer in your company, you're likely
> already doing something like that. If you're CI-only, there're no
> changes for you. If you're a developer - yeah, you'd have to learn a
> new flag.
Learn a new flag?
What I'm saying is, if you're doing regular builds as a developer, and
*then* realize you need trace_printk(), doing your suggested 'make D=1'
rebuilds *everything*. Not exactly something you want in the middle of
your development flow.
I'd *rather* manually add that #include where needed, and rebuild just
those files. I don't even feel very strongly about the whole thing,
other than the D=1 being the worst suggestion so far in the thread.
BR,
Jani.
>
> The real problem of course is the status inflation. The fact that
> defconfig enables CONFIG_EXPERT and CONFIG_DEBUG_KERNEL implies that
> every random person who is able to do:
>
> git clone && make && sudo make install
>
> now assumed an expert kernel user and active developer. It is not
> correct, and it leads to bloating kernel with dev-only features.
>
> What we discuss here is a new marker for those real experts and
> developers, I think. (In an hope that it will inflate not very fast.)
>
> Thanks,
> Yury
--
Jani Nikula, Intel
next prev parent reply other threads:[~2026-01-05 18:31 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-25 17:09 [PATCH v4 0/7] Unload linux/kernel.h Yury Norov (NVIDIA)
2025-12-25 17:09 ` [PATCH v4 1/7] kernel.h: drop STACK_MAGIC macro Yury Norov (NVIDIA)
2025-12-25 17:09 ` [PATCH v4 2/7] moduleparam: include required headers explicitly Yury Norov (NVIDIA)
2025-12-25 17:09 ` [PATCH v4 3/7] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h Yury Norov (NVIDIA)
2025-12-25 17:09 ` [PATCH v4 4/7] kernel.h: include linux/instruction_pointer.h explicitly Yury Norov (NVIDIA)
2025-12-25 17:09 ` [PATCH v4 5/7] tracing: Remove size parameter in __trace_puts() Yury Norov (NVIDIA)
2025-12-25 17:09 ` [PATCH v4 6/7] tracing: move tracing declarations from kernel.h to a dedicated header Yury Norov (NVIDIA)
2025-12-25 17:09 ` [PATCH v4 7/7] kernel.h: drop trace_printk.h Yury Norov (NVIDIA)
2025-12-26 16:58 ` Steven Rostedt
2025-12-27 14:45 ` Andy Shevchenko
2025-12-27 15:57 ` Steven Rostedt
2025-12-27 19:35 ` Yury Norov
2025-12-27 21:27 ` Steven Rostedt
2025-12-28 21:31 ` Andrew Morton
2025-12-29 16:17 ` Steven Rostedt
2025-12-29 16:41 ` Danilo Krummrich
2025-12-29 17:19 ` Borislav Petkov
2025-12-29 22:25 ` Mathieu Desnoyers
2025-12-30 8:55 ` Andy Shevchenko
2025-12-30 14:21 ` Mathieu Desnoyers
2025-12-30 16:18 ` Yury Norov
2025-12-30 16:46 ` Steven Rostedt
2026-01-03 0:50 ` Joel Fernandes
2026-01-03 12:57 ` Andy Shevchenko
2026-01-03 14:22 ` Yury Norov
2026-01-05 9:29 ` Jani Nikula
2026-01-05 16:36 ` Yury Norov
2026-01-05 16:50 ` Steven Rostedt
2026-01-05 18:30 ` Jani Nikula [this message]
2026-01-03 15:36 ` Joel Fernandes
2026-01-04 0:20 ` Andy Shevchenko
2026-01-05 16:39 ` Steven Rostedt
2026-01-05 17:11 ` Joel Fernandes
2026-01-05 18:21 ` Christophe Leroy (CS GROUP)
2026-01-05 19:33 ` Joel Fernandes
2026-01-05 20:04 ` Steven Rostedt
2026-01-05 20:15 ` Joel Fernandes
2026-01-05 18:02 ` Andy Shevchenko
2026-01-05 18:07 ` Yury Norov
2026-01-05 18:11 ` Andy Shevchenko
2025-12-27 14:50 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7df7c705c02cae6d609a3bc5f153082cf0658a60@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=andi.shyti@kernel.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=chleroy@kernel.org \
--cc=da.gomez@kernel.org \
--cc=dakr@kernel.org \
--cc=david.laight@runbox.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=joelagnelf@nvidia.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=mingo@kernel.org \
--cc=petr.pavlu@suse.com \
--cc=rafael@kernel.org \
--cc=rdunlap@infradead.org \
--cc=rodrigo.vivi@intel.com \
--cc=rostedt@goodmis.org \
--cc=tursulin@ursulin.net \
--cc=yury.norov@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox