Re: [Ksummit-discuss] [TECH TOPIC] printk redesign

[Josh Triplett <josh@joshtriplett.org>]

On Mon, Jun 19, 2017 at 02:21:46PM +0900, Sergey Senozhatsky wrote:
> Hello,
> 
> 	I, Petr Mladek and Steven Rostedt would like to propose a printk
> tech topic (as suggested by Steven). We are currently exploring the idea
> of complete redesign and rework of printk and it would be extremely helpful
> to hear from the community. printk serves different purposes, and some of
> requirements of printk tend to contradict each other; printk is monolithic
> and quite heavy, no wonder, it causes problems sometimes.
> 
> 	So the questions are (a short list) - what the new printk should be?
> should it remain monolithic, or can we split it? (e.g. core kernel messages
> don't share the log buffer with debug/info messages, etc.) what are the
> printk requirements? I've started playing with the idea of moving printk to
> per-CPU model: log buffers, per-CPU printk flusher threads. does is it make
> sense (wrt to printk requirements) to have direct and in-direct flushers of
> printk messages (e.g. core kernel messages are printed directly; debug/info
> messages are printed by printing kthreads, etc. well, unless in panic)? ...
> 
> 	There are many other questions, so it'd be great to have a
> brainstorming session.

It'd be nice if, when building a kernel with CONFIG_PRINTK disabled, the
full format-string handling wasn't compiled in to handle snprintf and
family. In particular, some of the kernel-specific %p format-string
modifiers only get used when printing to a user, never when formatting a
string for machine consumption. I can think of a few different ways to
address that, but I'd love to see that taken into account in the
requirements for a printk redesign.