From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: Date: Fri, 15 Aug 2008 08:39:52 -0700 From: "Tim Hockin" Subject: Re: [patch 1/3] kmsg: Kernel message catalog macros. In-Reply-To: <20080815112117.GP10078@bolzano.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080730165656.118280544@de.ibm.com> <20080730171156.824640459@de.ibm.com> <1218733457.2651.11.camel@localhost> <1218769739.24527.76.camel@localhost> <20080815034419.GB803@suse.de> <20080815112117.GP10078@bolzano.suse.de> Sender: linux-kernel-owner@vger.kernel.org List-Archive: List-Post: To: Jan Blunck Cc: Greg KH , Joe Perches , schwidefsky@de.ibm.com, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, lf_kernel_messages@lists.linux-foundation.org, Andrew Morton , Michael Holzheu , Gerrit Huizenga , Randy Dunlap , Jan Kara , Pavel Machek , Sam Ravnborg , =?UTF-8?Q?Jochen_Vo=C3=9F?= , Kunai Takashi , Tim Bird List-ID: On Fri, Aug 15, 2008 at 4:21 AM, Jan Blunck wrote: > On Thu, Aug 14, Tim Hockin wrote: > >> On Thu, Aug 14, 2008 at 8:44 PM, Greg KH wrote: >> > >> > What is wrong with what we have already agreed to standardise on here >> > people? dev_printk() for devices! It uniquely shows the device, what >> > driver is bound to it (if any), the bus id, and everything else. >> >> Part of the problem, imho, is the "if any" part. But I am more than happy to >> build on existing solutions. All the world is not a dev, though. I'd like to >> be able to report something like an OOM kill in (roughly) the same way as an >> ATA error, and I want (though could be talked out of) a way to tell these >> "events" (for lack of a better word) apart from plain-old-printk()s. > > I don't think that he wants to unify all the printk's in the system. I don't > think that reporting all errors "in the same way as an ATA error" makes any > sense. That would just lead to very stupid and unnatural messages for all > errors that are not like "ATA errors". Annotation of existing errors is a much > more flexible and feasible solution to that problem. Please don't misinterpret. I don't want to make other errors parse like an ATA error, I want to make the plumbing be parallel. I want one umbrella mechanism for reporting things that are more important than just-another-printk(). Because frankly, "parse dmesg" is a pretty crappy way to have to monitor your system for failures, and I am tired of explaining to people why we still do that. Tim