[lkml]   [2012]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH RESEND 1/3] printk: convert byte-buffer to variable-length record buffer
    On Sat, May 26, 2012 at 1:11 PM, Anton Vorontsov
    <> wrote:

    >> Subject: printk: convert byte-buffer to variable-length record buffer
    > Bad news, this patch breaks all kmsg_dump users.
    > Per current printk.c:
    >  * The 'struct log' buffer header must never be directly exported to
    >  * userspace, it is a kernel-private implementation detail that might
    >  * need to be changed in the future, when the requirements change.
    > But kmsg_dump users get the raw log, not text. Some users may even
    > use strlen() on the buffers, e.g. ramoops module was using it just
    > recently, before persistent_ram rework.
    > So, starting from this patch every kmsg_dump user is getting the
    > binary stuff, which is barely usable, and breaks a longstanding
    > user-visible ABIs (e.g. mtdoops, oops dumping into nvram on PowerPC,
    > and ramoops of course).

    These cases export their own format, it's just that the dump routines
    could copy the buffer in only two steps (beginning and end of the ring
    buffer), while in the future their code would need an update to copy
    it record for record now. The exported format in the dump does not
    necessarily need to change.

    It should be possible to convert them pretty easily to do that, they
    operate on their own allocated buffers already. Some of them seem to
    mangle the line-buffer already, so they should be able to copy
    record-by-record either.

    > I'm not sure how we can fix this without allocating a huge buffer
    > (and thus wasting memory), or reworking the whole kmsg_dump concept
    > and its users.

    I think an iterator in the dumper code is nicer and simpler. It will
    even provide structured data to the dumper, if the dumper wants to
    make use of it in the future. The prefix mangling of the text in the
    nvram dumper could surely benefit from that.

    The iterator would basically work similar to the printing of the whole
    buffer at a newly registered boot console, which was doing a similar
    logic as the dumper does.

    > p.s. And, btw, during HW bring-up, when there's even no serial
    > console usable, I somewhat liked to directly print log_buf memory
    > from a JTAG debugger, and thus see the kernel logs. Now that'll
    > look ugly. Heh. :-)

    Yeah, that probably does not look pretty anymore, but it still all
    works, right? Doesn't have he debugger a strings(1)-like output to
    print of a memory area?

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2012-05-27 16:41    [W:0.026 / U:67.440 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site