[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201312041922.59181.arnd@arndb.de>
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/
Powered by blists - more mailing lists