On Mon, 05 Jan 2026, Yury Norov <[email protected]> wrote: > On Mon, Jan 05, 2026 at 11:29:51AM +0200, Jani Nikula wrote: >> On Sat, 03 Jan 2026, Yury Norov <[email protected]> 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
