[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080815112117.GP10078@bolzano.suse.de>
Date: Fri, 15 Aug 2008 13:21:17 +0200
From: Jan Blunck <jblunck@...e.de>
To: Tim Hockin <thockin@...kin.org>
Cc: Greg KH <gregkh@...e.de>, Joe Perches <joe@...ches.com>,
schwidefsky@...ibm.com, linux-kernel@...r.kernel.org,
linux-s390@...r.kernel.org,
lf_kernel_messages@...ts.linux-foundation.org,
Andrew Morton <akpm@...ux-foundation.org>,
Michael Holzheu <holzheu@...ibm.com>,
Gerrit Huizenga <gh@...ibm.com>,
Randy Dunlap <randy.dunlap@...cle.com>,
Jan Kara <jack@...e.cz>, Pavel Machek <pavel@....cz>,
Sam Ravnborg <sam@...nborg.org>,
Jochen Voß <jochen.voss@...glemail.com>,
Kunai Takashi <kunai@...ux-foundation.jp>,
Tim Bird <tim.bird@...sony.com>
Subject: Re: [patch 1/3] kmsg: Kernel message catalog macros.
On Thu, Aug 14, Tim Hockin wrote:
> On Thu, Aug 14, 2008 at 8:44 PM, Greg KH <gregkh@...e.de> 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.
If I interpret Martins patches correctly he wants to be able to put add
extended information to specific messages the kernel is printing. This is a
good way to explain the rational of certain situations to people unwilling to
read the sources ;)
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists