[Ksummit-discuss] [TECH TOPIC] printk redesign

[Arnd Bergmann]

On Tue, Jun 20, 2017 at 1:46 AM, Josh Triplett <josh at joshtriplett.org> wrote:
> 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.

I don't think that's realistic, given how many special formats we have
nowadays, see the discussion about the 'struct rtc_time' format recently,
which was definitely meant for external ABIs.

        Arnd