The initial implementation is sending all new kernel messages appearing since LKRG is loaded. We probably want to add a knob to choose between several modes:
Send new LKRG messages only (no non-LKRG, no old).
Send new LKRG and non-LKRG messages only (no old). This is the current behavior.
Send all kernel messages (including old - that is, those buffered by the kernel prior to LKRG loading).
We could also have:
Like 3 on first LKRG load, like 2 on subsequent reloads.
However, the implementation for 4 is tricky/hackish - how do we determine that LKRG had already been loaded in this kernel's uptime? We're going to go through the buffered messages anyway, and could infer from there, but this means going through them twice (first to see no mentions of LKRG, then to send the buffered messages). Alternatively, we could leave some in-kernel flag even upon LKRG unloading, so we could check it on a subsequent LKRG reload easily.
We could also easily have:
Send all LKRG messages, including old (but no non-LKRG).
However, why would we? In case LKRG was loaded without networking, then is reloaded with networking? Sounds like too much of a special case to bother.
Nov 9, 2022
The initial implementation is sending all new kernel messages appearing since LKRG is loaded. We probably want to add a knob to choose between several modes:
We could also have:
However, the implementation for 4 is tricky/hackish - how do we determine that LKRG had already been loaded in this kernel's uptime? We're going to go through the buffered messages anyway, and could infer from there, but this means going through them twice (first to see no mentions of LKRG, then to send the buffered messages). Alternatively, we could leave some in-kernel flag even upon LKRG unloading, so we could check it on a subsequent LKRG reload easily.
We could also easily have:
However, why would we? In case LKRG was loaded without networking, then is reloaded with networking? Sounds like too much of a special case to bother.