Messages in this thread | | | Date | Sat, 26 May 2012 04:11:43 -0700 | From | Anton Vorontsov <> | Subject | Re: [PATCH RESEND 1/3] printk: convert byte-buffer to variable-length record buffer |
| |
Hello Kay,
On Thu, May 03, 2012 at 02:29:13AM +0200, Kay Sievers wrote: > From: Kay Sievers <kay@vrfy.org> > 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).
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.
Ideas?
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. :-)
-- Anton Vorontsov Email: cbouatmailru@gmail.com
| |