[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m1y6wmxlg3.fsf@fess.ebiederm.org>
Date: Wed, 04 Feb 2009 07:37:16 -0800
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Neil Horman <nhorman@...driver.com>
Cc: Simon Horman <horms@...ge.net.au>, hbabu@...ibm.com,
kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Vivek Goyal <vgoyal@...hat.com>
Subject: Re: [PATCH]: add dmesg log symbols to /proc/vmcoreinfo lists
Neil Horman <nhorman@...driver.com> writes:
>>
>> That aside we aren't currently exporting log_buf_len, so I don't
>> think this code works actually works.
>>
>> Neil can you add a comment in kernel/printk.c of the algorithm
>> necessary for external tools to decode the ring buffer?
>>
>> We need the comment because people working on kernel/printk.c
>> need to know what is happening and without having to review lots
>> of user space code, and we need the comment to verify that we
>> are exporting the right things.
>>
>
> Ok, as per Erics comment, I've written this. It applies on top of whats already
> in your tree Andrew. It adds some comments on the function in question so that
> anyone working on printk.c will know why we're exporting their symbols. It also
> modifies slightly the symbols we are exporting so that we can handle dmesg
> buffers that are longer than the standard PAGE_SIZE configuration, and lets us
> detect and handle buffer wraps.
Looks like a good start but what is the algorithm for using the variables?
Given a kernel core file how do you extract the dmesg ring buffer?
It still does not appear obvious to me that you are extracting the
dmesg ring buffer correctly or easily.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists