Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754345AbYHQDkc (ORCPT ); Sat, 16 Aug 2008 23:40:32 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751631AbYHQDkY (ORCPT ); Sat, 16 Aug 2008 23:40:24 -0400 Received: from planb.casita.net ([69.55.228.155]:4413 "EHLO planb.casita.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751572AbYHQDkY (ORCPT ); Sat, 16 Aug 2008 23:40:24 -0400 Date: Sat, 16 Aug 2008 23:39:03 -0400 (EDT) From: Rick Troth To: Tim Hockin cc: schwidefsky@de.ibm.com, Rusty Russell , 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 , =?UTF-8?Q?Jochen_Vo=C3=9F?= , Kunai Takashi , Tim Bird Subject: Re: [patch 1/3] kmsg: Kernel message catalog macros. In-Reply-To: Message-ID: References: <20080730165656.118280544@de.ibm.com> <200808131433.02966.rusty@rustcorp.com.au> <1218733623.2651.14.camel@localhost> <200808150922.23277.rusty@rustcorp.com.au> <1218908985.6037.12.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1962 Lines: 46 This is really an easy thing to do. It can be achieved without a huge retro-fit. It can happen even without yet another macro. (Not saying that there should not be a new macro or new function, just that we can enjoy unique message IDs without those mechanisms.) Martin Schwidefsky said: > > Ok, so a specialized version of printk will do the work to calculate > > the hash. Only, what will we do if there ever is a conflict? The message > > tag has to be unique. The shorter the hash is, the more likely a > > collision gets. Don't know if 6 hash digits is enough to just ignore the > > problem. Point to note: the message tag has to be unique. The tag is what's relevant, what gets catalogued. I don't really see the value of a hash per se. What Martin has suggested (unless I have misunderstood) is the driver name combined with some index number ==> unique msg id. That's not exactly a "hash". (One can generate a hash from it, but why bother? You've got a unique string already.) Then Tim Hockin wrote: > And if you ever need to change the text that is in the format string? > The hash changes. That seems exactly counter to your goal... Whether hashed or not, what's needed is premeditated reporting, intentional dividing between variable content (like device ID) and the explanatory text arround it. Prefix each line with a token (or as most are calling it, a "tag") that can be looked up off-line. I hope no one is thinking gettext in this thread. Don't clutter the kernel with something like gettext. And don't burden the kernel with run-time text crunching. Message codes go in when the module is written. They get looked up either in user space or off-line. Easy! Almost trivial! -- R; <>< -- 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/