Re: [PATCH 3/3] printk: implement support for extended console drivers

[Tejun Heo <tj@kernel.org>]

Hello, Andrew.

On Thu, Apr 30, 2015 at 02:31:28PM -0700, Andrew Morton wrote:
> So if I'm understanding this correctly, the /dev/kmsg output is altered
> (different cont handling) if some console registers with CON_EXTENDED
> (and there are no such consoles yet, so the patch is a no-op).

Yeah, that's mostly right.  /dev/kmsg output already has
"continuation" flag which indicates whether a message should be
concatenated which gets triggered occassionally currently.  This would
make use of that behavior a lot more frequently.

> If correct, this seems undesirable - registration of a CON_EXTENDED
> console collaterally damages the /dev/kmsg interface?  If the user has
> an app which depends on the original /dev/kmsg format then they'll be
> wondered what-the-heck-just-happened?

For applications which ignore the continuation flags, this would lead
to a different output.  We can fake it for /dev/kmsg (concatenate from
the kernel side and then output empty message for the later fragments)
but that'd be piling more hacks on top of already unnecessary hack
which is the cont buffer.

We can generate a log message indicating that the new mode is enabled
to make it easier to figure out why it changed.  Given that this is
not an entirely new behavior and the usage of extended console is
likely to stay fairly specific, transitioning this way is unlikely to
cause too much trouble especially given that most traditional tools
use the older interfaces w/o metadata which aren't affected by this
change.

What do you think?

Thanks.

-- 
tejun