[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.1010251821260.3955@localhost6.localdomain6>
Date: Mon, 25 Oct 2010 18:38:40 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Andi Kleen <andi@...stfloor.org>
cc: Huang Ying <ying.huang@...el.com>, Ingo Molnar <mingo@...e.hu>,
Len Brown <lenb@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
Borislav Petkov <petkovbb@...glemail.com>,
"H. Peter Anvin" <hpa@...or.com>, Don Zickus <dzickus@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Mauro Carvalho Chehab <mchehab@...hat.com>,
Tony Luck <tony.luck@...el.com>
Subject: Re: [NAK] Re: [PATCH -v2 9/9] ACPI, APEI, Generic Hardware Error
Source POLL/IRQ/NMI notification type support
On Mon, 25 Oct 2010, Andi Kleen wrote:
> > > Sigh, please integrate all this into EDAC (drivers/edac/) properly, instead of
> > > turning it into YET ANOTHER hardware vendor special hw-errors thing. We can do
> > > better than this. EDAC is almost there: it has support for Nehalem, AMD, a couple
> > > of older chips.
> >
> > I think APEI (ACPI Platform Error Interface) is another driver. Why
> > integrate two drivers?
>
> Yes they're solving quite different problems from EDAC with different
> interfaces and for different devices in the ACPI space.
>
> The earlier nack seems to be based on a lot of confusion on what the code
> does.
Errm. That patch series carries a lot of other weird stuff including a
new "memory allocator", a new ioremap implementation private to the
acpi code and new character device driver for hardware error
reporting.
> Subject: [PATCH -v2 5/9] Hardware error device core
>
> Hardware error device is a kind of device which can report hardware
> errors. The examples of hardware error device include APEI GHES, PCIe
> AER, etc.
>
> Hardware error device core in this patch provides common services for
> various hardware error devices.
But it does not even make an attempt to explain why this error
reporting cannot be done via the existing interfaces and why they
can't be extended to fit your needs. What's so special about APEI GHES
and PCIe AER that we need another incompatible "just fits your needs"
ABI which makes tooling folks deal with another completely different
interface ?
The only explanation I have is that you are simply not willing to work
with others and this is just another proof of a repeating problem.
Thanks,
tglx
--
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