lkml.org 
[lkml]   [2005]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patches in this message
    /
    Date
    From
    Subject[PATCH] Fix bytecount result from printk()
    printk() returns a bytecount, which nothing actually appears to use.

    This count is generated internally in vprintk(),
    and is off-by-3 for one particular path through that function.

    This patch fixes it to be consistent with how it is calculated
    for the other paths through that same function (vprintk).

    Whether or not the count should even exist in the first place
    is still a question for examination -- nothing appears to use it.

    On a related note, WHY does the LOG LEVEL format <6> not get
    interpreted correctly for the first printk() after an oops report?
    As in this example -- the <6> is printed, instead of being interpreted:

    kernel: <6>note: insmod[31060] exited with preempt_count 1

    Here's the off-by-3 fix patch.

    Signed-off-by: Mark Lord <lkml@rtr.ca>

    --- linux-2.6.15-rc3/kernel/printk.c.orig 2005-11-29 23:24:19.000000000 -0500
    +++ linux/kernel/printk.c 2005-12-01 10:01:39.000000000 -0500
    @@ -592,8 +592,8 @@
    emit_log_char(default_message_loglevel
    + '0');
    emit_log_char('>');
    - }
    - printed_len += 3;
    + } else
    + printed_len += 3;
    }
    log_level_unknown = 0;
    if (!*p)--- linux-2.6.15-rc3/kernel/printk.c.orig 2005-11-29 23:24:19.000000000 -0500
    +++ linux/kernel/printk.c 2005-12-01 10:01:39.000000000 -0500
    @@ -592,8 +592,8 @@
    emit_log_char(default_message_loglevel
    + '0');
    emit_log_char('>');
    - }
    - printed_len += 3;
    + } else
    + printed_len += 3;
    }
    log_level_unknown = 0;
    if (!*p)
    \
     
     \ /
      Last update: 2005-12-01 16:58    [W:0.041 / U:0.556 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site