linux-kernel - Re: [patch 1/3] kmsg: Kernel message catalog macros.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 15 Aug 2008 09:03:55 -0700
From:	Greg KH <gregkh@...e.de>
To:	Tim Hockin <thockin@...kin.org>
Cc:	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, 2008 at 10:33:10PM -0700, 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.

No, but way over half the kernel is.

> 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.

That's great, then create something that can handle both!  Don't throw
away some wonderful information that way over half the kernel has access
to just because the minority doesn't.  That would mean that we would
loose information in those drivers overall.

thanks,

greg k-h
--
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/