This should not block and ensures that logs will still show up on the
serial port even if one of the log sinks blocks because for example the
graphics driver crashed, taking fbbootlogd with it. In the future we
might want to have a dedicated worker per log sink, but for now this
helps a log with debugging the graphics subsystem in a VM.
Unfortunately the scheme still has to be created by the daemon due to a
kernel bug, but once that is fixed, it would allow delayed spawning of
scheme daemons.
I hadn't meant to upstream it yet. I accidentally added it in a commit
touching the netstack. In any case this commit integrates the kernel log
copying directly into LogScheme.
The kernel log copying is meant to show the kernel log on the fbbootlogd
rendered bootlog. Even once the kernel graphical debug has been disabled
or if it never got enabled due to the bootloader not presenting a
framebuffer.
This avoid a deadlock when the process logging things is directly or
indirectly involved in receiving them too. Currently there is a
workaround for a part of this problem in fbbootlogd, but doing it
directly in logd is a lot simpler and catches more cases.
bjorn3