linux-kernel - Re: [PATCH 1/3] Introduce FW_INFO* functions and messages

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:	Wed, 4 Dec 2013 19:22:57 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Prarit Bhargava <prarit@...hat.com>, linux-kernel@...r.kernel.org,
	"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>
Subject: Re: [PATCH 1/3] Introduce FW_INFO* functions and messages

On Tuesday 03 December 2013, Andrew Morton wrote:
> I do wonder if it all should be generalised a bit - it creates a bunch
> of infrastructure which is specific to system firmware issues, but
> what's so special about firmware?  Why can't I use this infrastructure
> to log netdev errors or acpi errors or PM errors or...?  But I didn't
> think about it much ;)

I had similar thoughts when I read this, but I can also remember a bunch
of very overdesigned attempts to reorganize and structure the kernel
logging code. I lot of time was wasted in the past for things that
ended up being too invasive or inconsistent.

The other part I noticed about this particular patchset is that it's
not really "firmware" as such, but specifically PC wiht ACPI that
gets covered here. So rather than generalizing the code, another
option would be to narrow down the scope and make it
acpi_{warn,info,dbg} instead.

	Arnd
--
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/