From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1387BB9F for ; Mon, 19 Jun 2017 23:46:53 +0000 (UTC) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 855541FB for ; Mon, 19 Jun 2017 23:46:52 +0000 (UTC) Date: Mon, 19 Jun 2017 16:46:50 -0700 From: Josh Triplett To: Sergey Senozhatsky Message-ID: <20170619234650.GC30361@cloud> References: <20170619052146.GA2889@jagdpanzerIV.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170619052146.GA2889@jagdpanzerIV.localdomain> Cc: ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] [TECH TOPIC] printk redesign List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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.