Conversation

I’m fighting to keep trace_printk.h in kernel.h. If you use trace_printk() for debugging, and do not want to have to add:

#include <linux/trace_printk.h>

to every file you you want to add a trace_printk() to, please make yourself heard and respond to this email thread.

Otherwise, trace_printk() will become a bit more tedious to use.

https://lore.kernel.org/all/20251229111748.3ba66311@gandalf.local.home/

1
1
3

@rostedt It looks like a good candidate for a new CONFIG_TRACE_PRINTK default Y making the include conditional.

1
0
0
@DesnoyersMa I would actually make it CONFIG_HIDE_TRACE_PRINTK to allow those that don't want it included to be able to have that option. As right now it's something people want that build their kernels.
1
0
0

@rostedt whether we use reversed logic or not, what matters is the default Y or N.

1
0
0
@DesnoyersMa The default needs to keep how it is today the same. For hiding, it would be default N.
1
0
0

@rostedt indeed. Therefore, both CONFIG_TRACE_PRINTK (default Y) and CONFIG_HIDE_TRACE_PRINTK (default N) achieve the same purpose. I find the naming without reversed logic clearer.

1
0
0

@DesnoyersMa @rostedt there's a risk of Linus yelling if there's a new config option that's default Y. Maybe unless it's something you'd really want enabled as a random user. Not sure about trace_printk() which is for developers. A negative config could then be safer. I've suggested that way previously also to make static keys default enabled.

1
0
0

@vbabka @DesnoyersMa I’ve sent Linus default y configs before. But I always mention “this keeps previous behavior”. What gets him pissed off is when you send a default y for a new feature. If it’s something that doesn’t change his config, he hasn’t complained to me about it before.

0
0
1