Messages in this thread | | | From | Kay Sievers <> | Date | Wed, 9 May 2012 11:38:38 +0200 | Subject | Re: [PATCH RESEND 1/3] printk: convert byte-buffer to variable-length record buffer |
| |
On Wed, May 9, 2012 at 5:52 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Tue, May 8, 2012 at 4:14 AM, Kay Sievers <kay@vrfy.org> wrote: >> >> Yeah, we need to make sure, we never merge the (always racy) >> continuation printk() users with (non-racy) non-continuation users. >> Therefore KERN_CONT is required to suppress the newline and to merge the >> content with the earlier non-newline-terminated printk() line. > > Why?
The idea was: Prefixes are not used that often, but not using a prefix should not expose the user to wrongly get appended to an earlier non-terminated line of another thread.
The point was to limit the "risk" of wrong merges to users of continuation, and not to users which send ordinary "atomic" lines.
> I really think this is just a bug in the new code. > > KERN_CONT should not be needed if the previous printk didn't have a final "\n".
It significantly limits wrong merges, especially for users which can rightfully expect not to get a wrong merge.
> We made it easier to use printk for a reason a few months ago. The new > rules are: > > - If you have a KERN_<loglevel>, it *always* starts a new line, the > obvious exception being KERN_CONT > > - the loglevels *only* matter at the start of the printk - so if you > have '\n' embedded in a single printk, that changes nothing > what-so-ever. It's not line-based.
It is a different behaviour. "Innocent" users are not exposed to "risky" users.
> - if you didn't have a '\n', and don't have a loglevel, KERN_CONT is implied.
But a lot of stuff which does not look for continuation, has no prefix, hasn't it? I rather make the "I want to be appended" explicit, instead giving the "I don't care about the log level" any meaning.
I think continuation is special, and ideally should not be much used. We should not "optimize" for it, and not accept breakage introduced to ordinary users that way.
> Quite frankly, those three rules (a) make sense and (b) make things easy.
It's true, it's much easier, but it's also much less reliable.
> Breaking them now is a bug. Please don't go adding ugly KERN_CONT when > there really isn't any reason for it. Just fix the printk code you > broke.
I can do this, I just don't think it's the right thing to do.
I surely would prefer reliability over rather weird heuristics for special cases. Today, we should be able to trust at least non-continuation printk users, which we can't, if we do expose them to the very real problems of continuation.
Still not convinced? :)
Kay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |