linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Question: dev_err_probe() vs Printk Index
@ 2022-08-06  8:53 Christophe JAILLET
  2022-08-07  6:57 ` Greg KH
  0 siblings, 1 reply; 2+ messages in thread
From: Christophe JAILLET @ 2022-08-06  8:53 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-kernel, Kernel Janitors

Hi,

When a driver is using dev_err(), part of it is inlined and it:
    - takes advantage of dev_fmt()  [1]
    - implements Printk Index       [2]

Printk Index works with some __builtin_constant_p() magic in it.
In case of a use in a probe, 99.99% of the time the log level and the 
format will be constant and the logic for Printk Index will be put in place.


In case dev_err_probe(), the format will be an argument passed to the 
function and will not be constant, so nothing will be generated in the 
'printk'_index section.


In case dev_err_probe(), a potential dev_fmt() defined in the drivers' 
file can't be taken into consideration.
(trusting my grep, we never use in files that define dev_fmt() in the .c 
file. I've not checked if it is true via #include "<something.h>")


Even if I've read [3], I don't fully understand the real need of this 
Printk Index mechanism (at least for my own needs :))


My questions are:
    - is my analysis right?
    - is the lack of these 2 functionalities (dev_fmt and Printk Index) 
expected, when dev_err_probe() is used?
    - if not, is it a issue?
    - should it be at least documented?


(not sure who to put in copy of this mail)

CJ

[1]: 
https://elixir.bootlin.com/linux/v5.19/source/include/linux/dev_printk.h#L143
[2]: 
https://elixir.bootlin.com/linux/v5.19/source/include/linux/dev_printk.h#L107
[3]: Documentation/core-api/printk-index.rst

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Question: dev_err_probe() vs Printk Index
  2022-08-06  8:53 Question: dev_err_probe() vs Printk Index Christophe JAILLET
@ 2022-08-07  6:57 ` Greg KH
  0 siblings, 0 replies; 2+ messages in thread
From: Greg KH @ 2022-08-07  6:57 UTC (permalink / raw)
  To: Christophe JAILLET; +Cc: linux-kernel, Kernel Janitors

On Sat, Aug 06, 2022 at 10:53:16AM +0200, Christophe JAILLET wrote:
> Hi,
> 
> When a driver is using dev_err(), part of it is inlined and it:
>    - takes advantage of dev_fmt()  [1]
>    - implements Printk Index       [2]
> 
> Printk Index works with some __builtin_constant_p() magic in it.
> In case of a use in a probe, 99.99% of the time the log level and the format
> will be constant and the logic for Printk Index will be put in place.
> 
> 
> In case dev_err_probe(), the format will be an argument passed to the
> function and will not be constant, so nothing will be generated in the
> 'printk'_index section.
> 
> 
> In case dev_err_probe(), a potential dev_fmt() defined in the drivers' file
> can't be taken into consideration.
> (trusting my grep, we never use in files that define dev_fmt() in the .c
> file. I've not checked if it is true via #include "<something.h>")
> 
> 
> Even if I've read [3], I don't fully understand the real need of this Printk
> Index mechanism (at least for my own needs :))
> 
> 
> My questions are:
>    - is my analysis right?
>    - is the lack of these 2 functionalities (dev_fmt and Printk Index)
> expected, when dev_err_probe() is used?
>    - if not, is it a issue?
>    - should it be at least documented?

The printk index stuff is odd, and always seemed like a "check box"
option that some people wanted for a niche enterprise market.  It's up
to them to keep that working well if they really need it, driver authors
should not worry about this.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-08-07  6:58 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-06  8:53 Question: dev_err_probe() vs Printk Index Christophe JAILLET
2022-08-07  6:57 ` Greg KH

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).