Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753681AbYHYQEf (ORCPT ); Mon, 25 Aug 2008 12:04:35 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754577AbYHYQEX (ORCPT ); Mon, 25 Aug 2008 12:04:23 -0400 Received: from mtagate5.de.ibm.com ([195.212.29.154]:65191 "EHLO mtagate5.de.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754538AbYHYQEW (ORCPT ); Mon, 25 Aug 2008 12:04:22 -0400 Subject: Re: [patch 1/3] kmsg: Kernel message catalog macros. From: Martin Schwidefsky Reply-To: schwidefsky@de.ibm.com To: Rusty Russell Cc: linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, lf_kernel_messages@lists.linux-foundation.org, Andrew Morton , Michael Holzheu , Gerrit Huizenga , Greg Kroah-Hartman , Randy Dunlap , Jan Kara , Pavel Machek , Sam Ravnborg , Joe Perches , Jochen =?ISO-8859-1?Q?Vo=DF?= , Kunai Takashi , Tim Bird In-Reply-To: <200808131433.02966.rusty@rustcorp.com.au> References: <20080730165656.118280544@de.ibm.com> <20080730171156.824640459@de.ibm.com> <200808131433.02966.rusty@rustcorp.com.au> Content-Type: text/plain Organization: IBM Corporation Date: Mon, 25 Aug 2008 17:56:30 +0200 Message-Id: <1219679790.16131.28.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1398 Lines: 32 On Wed, 2008-08-13 at 14:33 +1000, Rusty Russell wrote: > On Thursday 31 July 2008 02:56:57 Martin Schwidefsky wrote: > > From: Michael Holzheu > > From: Martin Schwidefsky > > > > Introduce a new family of printk macros which prefixes each kmsg message > > with a component name and allows to tag the printk with a message id. > > Can you hash the format string to generate the id? 6 hex digits should be > enough, and your tool can check for clashes. As it's bad form to have > identical strings for different semantics anyway, this seems to make sense. If we go with hashes there is one more thing: kmsg(0, ) The variant where we manually assign the message ids knows about the "special" id 0. There is no documentation required for id 0 and none is wanted. If we replace the manual ids with hashes this will get lost. You could argue that a kmsg with id 0 is a normal printk so why not just use printk? What is lost is the information that this printk has been found to be not important enough to be documented. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/