Re: instrumentation, was Re: core dump analysis

[Geert Uytterhoeven <geert@linux-m68k.org>]

Hi Michael,

On Tue, Apr 11, 2023 at 6:56 AM Michael Schmitz <schmitzmic@gmail.com> 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@linux-m68k.org

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