Re: instrumentation, was Re: core dump analysis

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Michael,

On Tue, Apr 11, 2023 at 6:56 AM Michael Schmitz <schmitzmic@xxxxxxxxx> wrote:
Am 11.04.2023 um 12:20 schrieb Finn Thain:
On Sun, 9 Apr 2023, Michael Schmitz wrote:
Am 08.04.2023 um 00:06 schrieb Geert Uytterhoeven:
On Fri, Apr 7, 2023 at 3:58 AM Michael Schmitz <wrote:
The easiest way to do that is to log all wait and signal syscalls, as
well as process exit. That might alter timing if these log messages
go to the serial console though. Is that what you have in mind?

Store to RAM, retrieve through a new /proc file?

Yes, that could be done, though I'd rather avoid duplicating a lot of
the generic message formatting code (printk and friends).

I'll have a look around ...


A better solution might be be to port the existing instrumentation like
ftrace, kprobes, uprobes etc. Might be a lot of work though. I wonder
how portable that stuff is.

If you use printk, you could probably avoid most of the delays by enabling
the dummy console. Then the kernel messages would be collected with dmesg,
given a sufficiently large CONFIG_LOG_BUF_SHIFT. But it would be
inconvenient to have no serial console available for the usual purposes.

Can we disable the serial console after boot, by registering the dummy
console? Or will that just log messages to both?

You can increase loglevel.

Gr{oetje,eeting}s,

                        Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds



[Index of Archives]     [Video for Linux]     [Yosemite News]     [Linux S/390]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux