On Fri, Sep 04, 2020 at 06:31:13PM +0900, ��� wrote: > > On Fri, Sep 04, 2020 at 05:24:38PM +0900, Changki Kim wrote: > > > Printk() meesages are the most basic and useful debug method. > > > However, additional information needs in multi-processor. > > > If we add messages with processor id and process name, we can find a > > > problem only with messages when the problem occurs with H/W IP or CPU. > > > This is very useful in narrowing down the scope of the problems. > > > > > > Therefore, instead of trying to help buffering, let's try to help > > > reconstructing messages by saving caller information as of calling > > > log_store() and adding it as "[$processor_id: $process_name: > > $thread_id]" > > > upon printing to consoles. > > > > > > Some examples for console output: > > > > > > [ 0.059580] [0: swapper/0: 1] CPU: All CPU(s) started at > EL1i > > > [ 2.153157] [5: init: 1] migov: complete to probe > migov > > > [ 7.441317] [4: init: 1] NET: Registered protocol > family 39 > > > [ 22.793389] [5: kworker/u16:1: 184] SMP: stopping secondary CPUs > > > > > > Signed-off-by: Changki Kim <changki....@samsung.com> > > > --- > > > kernel/printk/printk.c | 20 ++++++++++++++++++-- > > > kernel/printk/printk_ringbuffer.h | 7 +++++++ > > > lib/Kconfig.debug | 16 ++++++++++++++++ > > > 3 files changed, 41 insertions(+), 2 deletions(-) > > > > Isn't the CPU number already present if you want it today? Why add it > > again? > > > > thanks, > > > > greg k-h > > CPU number isn't present now. If I enabled PRINTK_CALLER, > then it is present cpu id or thread id.
Great, that should give you what you need here, right? > The config isn't always present cpu id. What do you mean? > We need cpu id each each message. Why each message? What does that provide you? And if PRINTK_CALLER does not work properly, please fix it. I don't see how it would not work any different from your patch, you shouldn't duplicate things. thanks, greg k-h