|From:||Steven Rostedt <rostedt-AT-goodmis.org>|
|To:||Kay Sievers <kay-AT-vrfy.org>|
|Subject:||Re: [PATCH v2] printk: Have printk() never buffer its data|
|Date:||Mon, 25 Jun 2012 11:55:41 -0400|
|Cc:||Ingo Molnar <mingo-AT-kernel.org>, LKML <linux-kernel-AT-vger.kernel.org>, Linus Torvalds <torvalds-AT-linux-foundation.org>, Ingo Molnar <mingo-AT-elte.hu>, Greg Kroah-Hartman <gregkh-AT-linuxfoundation.org>, Wu Fengguang <fengguang.wu-AT-intel.com>, Andrew Morton <akpm-AT-linux-foundation.org>, Joe Perches <joe-AT-perches.com>, "Paul E. McKenney" <paulmck-AT-us.ibm.com>, Peter Zijlstra <a.p.zijlstra-AT-chello.nl>|
On Mon, 2012-06-25 at 17:22 +0200, Kay Sievers wrote: > On Mon, Jun 25, 2012 at 4:26 PM, Steven Rostedt <email@example.com> wrote: > > On Mon, 2012-06-25 at 15:56 +0200, Ingo Molnar wrote: > > >> Anyway, bike shed painting aside, the patch looks like a > >> workable solution to me. > > > > Great! Lets hope Kay feels the same way. > > Hmm, what I still miss, is how the log record export should work > properly with unbuffered continuation lines. > > The buffering of continuation line users resulted in a clean one > record per logged line. Now we will get all separated records for all > continuation prints of a single line, which would either need to be > merged in userspace, or internally. Merge it in userspace. > > Non-buffered continuation lines and and a record buffer don't play > that well with each other. Yeah, I know, as they seem to be a problem together in the coding. > It also sounds like quite a lot of wasted > headers in the buffer, which we need to carry around and throw away > when we reconstruct the line for output again. If we merge them > internally we mess around with the sequence numbers, if we merge them > in userspace we would need to export the flags to do that. As I'm still on debian and fedora 14, I have to admit that I do not quite understand exactly what you are trying to do with systemd or your logging facility. But it seems to become clear that printk isn't a tool for it. What exactly are you trying to record from the kernel? Device information, kernel diagnostics, or something else? Maybe there should be another facility besides printk that can pass what you want to your utilities. printk is the first line of attack for kernel developers to find their bugs. If it becomes bloated and focused on users, it will make development of the kernel much more difficult. Perhaps we should have added a hook or a tracepoint at the beginning of printk that your logging facility could attach to, and then it could do logging and buffering in any manner it would like, instead of hijacking the best debugging tool that kernel developers use. I'm starting to side with Ingo that the new printk should be reverted and rethought, and find another answer to the fixes that it solved. -- Steve
Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds