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 BEA14B4A for ; Mon, 19 Jun 2017 15:21:01 +0000 (UTC) Received: from vps0.lunn.ch (vps0.lunn.ch [178.209.37.122]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6DFD2185 for ; Mon, 19 Jun 2017 15:21:00 +0000 (UTC) Date: Mon, 19 Jun 2017 17:20:55 +0200 From: Andrew Lunn To: Steven Rostedt Message-ID: <20170619152055.GM3786@lunn.ch> References: <20170619052146.GA2889@jagdpanzerIV.localdomain> <20170619103912.2edbf88a@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170619103912.2edbf88a@gandalf.local.home> 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: , > Here's a couple of requirements that I expect from printk: > > 1) First and for most, is the critical output. Those of warnings, and > above. Basically all critical messages that can be used to debug a > system crash. This requires the ability to be executed from any > context, including NMI. > > This group includes WARN() and BUG() output, and anything in an oops. > > 2) Activity information. This too can be used to debug a system crash, > and requires serializations. When a device comes on line. A spurious > interrupt. A system state change (CPU going on or off line). > > 3) Status information. Now, I'm sure people will argue about what goes > in this or the above #2. Here, this would be all pr_info. Useful > information that should be logged, but perhaps not something that is > critical knowledge if a crash happens. In other words, something that > isn't critical to get out immediately. > > 4) All other kernel information that's not critical at all, and perhaps > doesn't even need to be serialized. At least, not against the above. > This could be cached, and outputted at a later time than when the > printk() was called. Developers machine probably have different requirements to production machines. When debugging during code development, i want the debug output to be in the correct order, independent of the level. If you are going to cause reordering, you might want to add a sequence number to each output, so it is possible to put it back into the correct order. And it needs to be clear when output is out of order. Andrew