Re: [PATCH] printk: export symbols for debug modules

[Enlin Mu]

Petr Mladek <pmladek@xxxxxxxx> 于2023年8月16日周三 17:31写道：
>
> On Wed 2023-08-16 09:24:29, Enlin Mu wrote:
> > Petr Mladek <pmladek@xxxxxxxx> 于2023年8月15日周二 21:55写道：
> > >
> > > On Tue 2023-08-15 10:07:11, Yunlong Xing wrote:
> > > > From: Enlin Mu <enlin.mu@xxxxxxxxxx>
> > > >
> > > > the module is out-of-tree, it saves kernel logs when panic
> > > >
> > > > Signed-off-by: Enlin Mu <enlin.mu@xxxxxxxxxx>
> > >
> > > I am fine with it. After all, this API seems to here for
> > > similar purposes.
> > Thanks.
> > >
> > > Acked-by: Petr Mladek <pmladek@xxxxxxxx>
> > >
> > > Of course, it would be better to maintain the module in upstream.
> > > Is there any chance to get it upstream? It seems that it
> > > is GPL-compatible so...
> > Yes, currently under development. Once the code debugging is stable,
> > it will be pushed to the community.
>
> Great.
>
> One more thing which came to my mind.
>
> The log buffer contains the plain text and "id" of the related
> metadata. Namely, there is always an "unsigned long" before
> each message, see struct prb_data_block.
>
> You might consider using the kmsg_dump API. It has been added
> for this purpose. It allows to read and store the messages
> one by one. And the messages are formatted the same way
> as on console or by dmesg.
>
> The registered dumpers are automatically called in panic().
> See kmsg_dump(KMSG_DUMP_PANIC) in panic().
Yes, I have use this API in panic.

But there is a special case where when the system hangs and all cores
are unable to execute panic processes, this API  cannot be used
anymore.

When this module starts, it obtains the virtual address of the log,
converts it into a physical one, and saves it to the specified
address. When uboot starts, obtain the above information, extract the
kernel log, and debug the cause of the exception.

>
> There are few users of this API. Look for kmsg_dump_register()
> to get some inspiration.
>
> Best Regards,
> Petr

Best Regards,
Enlin