include/linux/kernel.h: Add config option for pr_fmt(fmt)

Change the default #define pr_fmt(fmt) from:
- #define pr_fmt(fmt) fmt
to:
- #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

This will standard use of prefixes and prevent the addition of new #defines when using pr_<level>.

Adds a config option to use the old style if desired.

This adds prefixes to 326 strings in an x86 defconfig.

Broken out by subsystem/module, the prefixes are:

     10 acpi                
      2 act_api             
      2 af_inet             
      6 af_packet           
     22 apic                
      1 apic_noop           
      2 blktrace            
      1 boot                
      4 calibrate           
      1 centaur             
      2 cleanup             
      1 common              
      2 dev                 
      1 devinet             
     17 edac_mce_amd        
      1 ehci_hcd            
      1 fb                  
     13 generic             
      9 hibernate           
      2 i2c_algo_bit        
      1 io_delay            
      1 ip6table_filter     
      1 iptable_filter      
      2 iptable_nat         
      3 ipv6                
      2 irq                 
      8 kexec               
      5 libphy              
     19 main                
      2 manage              
     11 mce                 
      2 mount               
      1 msr                 
      5 nf_conntrack_ipv4   
      7 nf_conntrack_ipv6   
      4 nf_conntrack_netlink
      2 nfnetlink           
      2 nfnetlink_log       
      1 ohci_hcd            
      5 oom_kill            
      1 pcieportdrv         
      9 percpu              
     21 perf_event          
      1 pid                 
      2 platform            
      2 probe_32            
      1 rtc_cmos            
      2 setup               
      1 setup_bus           
      1 skbuff              
      1 sleep               
      8 smpboot             
      4 snapshot            
      3 suspend             
      6 swap                
      1 tcp_ipv4            
      8 trace               
     14 trace_events        
     26 trace_kprobe        
      3 trace_sched_switch  
      1 trace_stat          
      3 tsc_sync            
     10 usbcore             
      2 usb_storage         
     10 vgaarb              
      1 xt_state 

Some of these add useful info, others are redundant and can and will be trivially fixed by adding either a new line to #define pr_fmt(fmt) fmt to the sources or by removing the internal prefix strings in the existing pr_<level> calls.

Signed-off-by Joe Perches <[email protected]>

---
 include/linux/kernel.h |    4 ++++
 init/Kconfig           |   10 ++++++++++
 2 files changed, 14 insertions(+), 0 deletions(-)

include/linux/kernel.h +4 -0

index 1759ba5..9cb2e8f 100644
@@ -409,8 +409,12 @@ static inline char *pack_hex_byte(char *buf, u8
 byte)
 extern int hex_to_bin(char ch);
 
 #ifndef pr_fmt
+#ifdef CONFIG_PR_FMT_IS_KBUILD_MODNAME
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+#else
 #define pr_fmt(fmt) fmt
 #endif
+#endif
 
 #define pr_emerg(fmt, ...) \

         printk(KERN_EMERG pr_fmt(fmt), ##__VA_ARGS__)

init/Kconfig +10 -0

index 7b920aa..a406d1c 100644
@@ -897,6 +897,16 @@ config PRINTK
 	  very difficult to diagnose system problems, saying N here is
 	  strongly discouraged.
 
+config PR_FMT_IS_KBUILD_MODNAME
+	default y
+	depends on PRINTK
+	bool "Use KBUILD_MODNAME as prefix for pr_<level>"
+	help
+	  This option sets the default pr_fmt to KBUILD_MODNAME.
+	  This will prefix all pr_<level> logging message calls with the
+	  build system defined value unless there is an existing define
+	  of pr_fmt in the source code.
+
 config BUG
 	bool "BUG() support" if EMBEDDED
 	default y

Quoted 6 lines · Joe Perches

Change the default #define pr_fmt(fmt) from:
- #define pr_fmt(fmt) fmt
to:
- #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
This will standard use of prefixes and prevent the addition of new #defines when using pr_<level>.

I'm all for it!

Quoted 1 line

Adds a config option to use the old style if desired.

Not sure what the idea is. Once pr_fmt() includes the module name, we will drop hard-coded prefixes in all log messages throughout the kernel tree. Once this is done, a kernel built with PR_FMT_IS_KBUILD_MODNAME=n would become horribly confusing.

How relevant is the x86 defconfig?
It doesn't include any hardware-specific driver, does it?

I've used the following grep to find them: grep -I 'pr_[a-z]*([^"]' Let me know if you have anything better.

Quoted 8 lines · Jean Delvare

Quoted 6 lines · Joe Perches

Change the default #define pr_fmt(fmt) from:
- #define pr_fmt(fmt) fmt
to:
- #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
This will standard use of prefixes and prevent the addition of new #defines when using pr_<level>.

I'm all for it!

Quoted 5 lines

Quoted 1 line

Adds a config option to use the old style if desired.

Not sure what the idea is. Once pr_fmt() includes the module name, we will drop hard-coded prefixes in all log messages throughout the kernel tree. Once this is done, a kernel built with PR_FMT_IS_KBUILD_MODNAME=n would become horribly confusing.

True. The idea is to allow a transition period and remove this PR_FMT_IS_KBUILD_MODNAME config option later.

Quoted 8 lines · Jean Delvare

Quoted 6 lines · Joe Perches

Change the default #define pr_fmt(fmt) from:
- #define pr_fmt(fmt) fmt
to:
- #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
This will standard use of prefixes and prevent the addition of new #defines when using pr_<level>.

I'm all for it!

Quoted 5 lines

Quoted 1 line

Adds a config option to use the old style if desired.

Not sure what the idea is. Once pr_fmt() includes the module name, we will drop hard-coded prefixes in all log messages throughout the kernel tree. Once this is done, a kernel built with PR_FMT_IS_KBUILD_MODNAME=n would become horribly confusing.

True. The idea is to allow a transition period and remove this PR_FMT_IS_KBUILD_MODNAME config option later.

Quoted 2 lines

How relevant is the x86 defconfig?
It doesn't include any hardware-specific driver, does it?

It adds lots of x86 specific drivers...

Quoted 2 lines

I've used the following grep to find them: grep -I 'pr_[a-z]*([^"]' Let me know if you have anything better.

Perhaps use -P "\bpr_(emerg|alert|crit|err|warning|warn|notice|info|cont|debug)\s*\(\s*\"\w+:"

Another way is to use:
strings <vmlinux|other> | grep -P "^<.>\w+:"

Quoted 15 lines · Joe Perches

Quoted 13 lines · Jean Delvare

Quoted 6 lines · Joe Perches

Change the default #define pr_fmt(fmt) from:
- #define pr_fmt(fmt) fmt
to:
- #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
This will standard use of prefixes and prevent the addition of new #defines when using pr_<level>.

I'm all for it!

Quoted 1 line

Adds a config option to use the old style if desired.

Not sure what the idea is. Once pr_fmt() includes the module name, we will drop hard-coded prefixes in all log messages throughout the kernel tree. Once this is done, a kernel built with PR_FMT_IS_KBUILD_MODNAME=n would become horribly confusing.

Quoted 2 lines

True. The idea is to allow a transition period and remove this PR_FMT_IS_KBUILD_MODNAME config option later.

I don't buy this, sorry. During the "transition period", neither value of this option will produce good results. One will lead to duplicate prefixes and the other will lead to missing prefixes.

Quoted 19 lines · Jean Delvare

Quoted 17 lines · Joe Perches

Quoted 7 lines · Jean Delvare

Quoted 6 lines · Joe Perches

Change the default #define pr_fmt(fmt) from:
- #define pr_fmt(fmt) fmt
to:
- #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
This will standard use of prefixes and prevent the addition of new #defines when using pr_<level>.

Quoted 6 lines

I'm all for it!

Quoted 1 line

Adds a config option to use the old style if desired.

Not sure what the idea is. Once pr_fmt() includes the module name, we will drop hard-coded prefixes in all log messages throughout the kernel tree. Once this is done, a kernel built with PR_FMT_IS_KBUILD_MODNAME=n would become horribly confusing.

True. The idea is to allow a transition period and remove this PR_FMT_IS_KBUILD_MODNAME config option later.

Quoted 3 lines

I don't buy this, sorry. During the "transition period", neither value of this option will produce good results. One will lead to duplicate prefixes and the other will lead to missing prefixes.

So why don't you change it in your kernel.h and include that in linux-next and see how many complaints you get.

Quoted 16 lines · Joe Perches

Quoted 15 lines · Jean Delvare

Quoted 14 lines · Joe Perches

Quoted 13 lines · Jean Delvare

Quoted 6 lines · Joe Perches

Change the default #define pr_fmt(fmt) from:
- #define pr_fmt(fmt) fmt
to:
- #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
This will standard use of prefixes and prevent the addition of new #defines when using pr_<level>.

I'm all for it!

Quoted 1 line

Adds a config option to use the old style if desired.

Not sure what the idea is. Once pr_fmt() includes the module name, we will drop hard-coded prefixes in all log messages throughout the kernel tree. Once this is done, a kernel built with PR_FMT_IS_KBUILD_MODNAME=n would become horribly confusing.

Quoted 7 lines

Quoted 5 lines

Quoted 2 lines

True. The idea is to allow a transition period and remove this PR_FMT_IS_KBUILD_MODNAME config option later.

I don't buy this, sorry. During the "transition period", neither value of this option will produce good results. One will lead to duplicate prefixes and the other will lead to missing prefixes.

So why don't you change it in your kernel.h and include that in linux-next and see how many complaints you get.

It would seem awkward that the i2c or hwmon tree would touch kernel.h.

Besides, linux-next is meant for integration testing. We already know that the change will integrate fine, in that it won't cause a build failure or runtime crash. We also know that, without the tree-wide cleanup of many driver, the change will cause duplicate prefixes in many messages.

There's little point in testing something we know will not be good enough. Better prepare all the driver patches, and test the whole thing when it's ready. I know it will be a very large and intrusive patchset, but this can certainly be done with Andrew's support.

Quoted 10 lines · Jean Delvare

Besides, linux-next is meant for integration testing. We already know that the change will integrate fine, in that it won't cause a build failure or runtime crash. We also know that, without the tree-wide cleanup of many driver, the change will cause duplicate prefixes in many messages.

There's little point in testing something we know will not be good enough. Better prepare all the driver patches, and test the whole thing when it's ready. I know it will be a very large and intrusive patchset, but this can certainly be done with Andrew's support.

I think you underestimate the time, effort and acceptance levels by the various arches and maintainers required.

Also, it's not just drivers, it's arch, lib, and kernel. (...)

Hi Joe,

Sorry for the late answer.

Quoted 12 lines · Joe Perches

Quoted 10 lines · Jean Delvare

Besides, linux-next is meant for integration testing. We already know that the change will integrate fine, in that it won't cause a build failure or runtime crash. We also know that, without the tree-wide cleanup of many driver, the change will cause duplicate prefixes in many messages.

There's little point in testing something we know will not be good enough. Better prepare all the driver patches, and test the whole thing when it's ready. I know it will be a very large and intrusive patchset, but this can certainly be done with Andrew's support.

Quoted 5 lines

I think you underestimate the time, effort and acceptance levels by the various arches and maintainers required.

Also, it's not just drivers, it's arch, lib, and kernel. (...)

I've had time to think about it all some more, and I have to admit that my counter-proposal doesn't really fly. Changing everything at once throughout the whole kernel tree is simply too difficult.

So I hate to admit it, but your initial proposal was certainly better, because it can be done one subsystem at a time. So I think we should forget about my objections and go on with your first patchset.

Quoted 3 lines · Jean Delvare

Changing everything at once
throughout the whole kernel tree is simply too difficult. So I hate to admit it,

go on with your first patchset.
I pretty much came to the same conclusion. No objections here anymore either.

Quoted 4 lines · Guenter Roeck

Quoted 3 lines · Jean Delvare

Changing everything at once
throughout the whole kernel tree is simply too difficult. So I hate to admit it,

I try to value my own opinion rather less highly than I used to so I can discount it better when I'm proven wrong.

That must come from being married...

Quoted 2 lines

go on with your first patchset.
I pretty much came to the same conclusion. No objections here anymore either.

Is there anything you need from me?

I'll start applying the patches to my next tree. I'll get back to you if I run into trouble.

Jean, do you want to take some of the patches, or should I take them all ?

Hi Guenter,

Quoted 4 lines · Guenter Roeck

I'll start applying the patches to my next tree. I'll get back to you if I run into trouble.

Jean, do you want to take some of the patches, or should I take them all ?

I'll take the it87, lm78, pc87360, pc87427 and w83781d patches. Please take all the rest. Thanks!