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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
