lkml.org 
[lkml]   [2007]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 2/2] Colored kernel output (run3)

    On Oct 6 2007 23:25, Oleg Verych wrote:
    >> ---
    >> arch/x86_64/kernel/early_printk.c | 11 +++++++----
    >> drivers/char/Kconfig | 4 +++-
    >> drivers/char/vt.c | 32 ++++++++++++++++++++++++--------
    >> drivers/net/netconsole.c | 3 ++-
    >> drivers/serial/8250.c | 3 ++-
    >> drivers/serial/8250_early.c | 3 ++-
    >> include/linux/console.h | 2 +-
    >> kernel/printk.c | 12 +++++++-----
    >> 8 files changed, 48 insertions(+), 22 deletions(-)
    >
    >Making this amount changes and not thinking about more intelligent
    >coding of the functionality?

    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;
    }

    >I mean, *write() have nothing to do with loglevels. If they do
    >(suddenly), then why not to use a char in the *str to make it possible? I
    >might be wrong, but there are already macros before format strings in
    >printk().
    >
    >And this is not `loglevel' thing any more. It's attributes, which can be
    >used by many other drivers/file systems/schedulers/ what ever, if
    >developers, like Ingo, will extend printk() output to be more nice in
    >subsystems they develop.

    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
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-10-06 23:31    [W:0.099 / U:34.252 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site