On Tue, 11 Apr 2023, Michael Schmitz 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? >
I don't know. I'd have to experiment in QEMU or Aranym.
