On Wed, Oct 12, 2016 at 9:16 AM, Joe Perches <j...@perches.com> wrote: >> (but with the new world order you actually *can* combine KERN_CONT >> with a loglevel, so that if the beginning od the line got flushed, the >> continuation can still be printed with the right log level). > > I think that might not be a good idea. > > Anything that uses a KERN_CONT with a new log level > might as well be converted into multiple printks.
Generally yes. The immediate reason for it was some really really nasty and horrible indirection in the ACPI layer, which goes through something like fifteen million different abstraction layers before it actually hits "printk()", and some of them do vsprintf() in the middle. It was something like ACPI_INFO() -> acpi_os_printf() -> acpi_os_vprintf() which is completely broken and *always* has that KERN_CONT marker at the beginning, but earlier phases can have the level marker in it already.. In other words, it was a terminally broken piece of nasty code, but there was no way I was going to touch the ACPI "OS independent" layers, so I just said "screw this, if you want to mix KERN_CONT with a level marker, you can". So I agree, you normally shouldn't need to. In fact, the fewer KERN_CONT's I see in the kernel, the better off we are. But _sometimes_ KERN_CONT makes sense (and the OOM code is likely one of the few places where it really might be the best of a number of bad options: lots of information that needs to be pretty dense, and we obviously can't afford to allocate a buffer for it dynamically, and doing so statically isn't a great option either..) Linus