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 B23D0B93 for ; Tue, 20 Jun 2017 14:36:55 +0000 (UTC) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EF7F8184 for ; Tue, 20 Jun 2017 14:36:54 +0000 (UTC) Date: Tue, 20 Jun 2017 10:36:52 -0400 From: Steven Rostedt To: Arnd Bergmann Message-ID: <20170620103652.7719b715@gandalf.local.home> In-Reply-To: References: <20170619052146.GA2889@jagdpanzerIV.localdomain> <20170619234650.GC30361@cloud> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: ksummit Subject: Re: [Ksummit-discuss] [TECH TOPIC] printk redesign List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, 20 Jun 2017 10:24:43 +0200 Arnd Bergmann wrote: > > 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. I think it may be possible, but it is a separate project from the printk one. One thing, tracing requires it, and does not require printk. What you could do is have CONFIG_VSPRINTF and have anything that uses it select it as well. Which would be printk, tracing, etc. But the printk mess in general is a big enough issue to try to solve than to bring this up at this time. -- Steve