Well humm.. in an unmodified kernel, the last function that has
knowledge of the loglevel is _call_console_drivers() in kernel/printk.c.
From there, the call chain is directly -> __call_console_drivers() ->
drivers/char/vt.c:vt_console_print().
_call_console_drivers() skips the <N> substring and passes on the rest of the
message:
if (msg_level < 0 && ((end - cur_index) > 2) &&
LOG_BUF(cur_index + 0) == '<' &&
LOG_BUF(cur_index + 1) >= '0' &&
LOG_BUF(cur_index + 1) <= '7' &&
LOG_BUF(cur_index + 2) == '>') {
msg_level = LOG_BUF(cur_index + 1) - '0';
cur_index += 3;
start_print = cur_index;
}
If I interpret you correctly, you want me to remove cur_index+=3
and instead reparse <N> in drivers/char/vt.c. But that's not good,
because if you use serial, we won't go to vt.c, and in the end,
8250.c would also need to parse <N>, which I think is just walking
around the hill.
kernel/printk.c -> 8250.c -> grab_loglevel_from_string -> ignore it and print
message
kernel/printk.c -> vt.c -> grab_loglevel_from_string -> print color according
to loglevel
VS
kernel/printk.c -> pass loglevel directly to 8250.c -> ignore loglevel and
print message
kernel/printk.c -> pass loglevel directly to vt.c -> print color according to
loglevel
-
