Re: [PATCH -v3 0/8] ACPI, APEI patches for 2.6.37

[Andi Kleen]

Peter,

> All you've done is decreased the arch/x86/ footprint of the patch
> series, but neither you nor Andi have addressed the technical arguments
> against adding this ABI.

What were the technical arguments? I don't remember any.

I remember just reading some rants from people who clearly
never even looked at this code and made no attempt to review
it. It was very untechnical.

> Nor have you engaged in conversation with the other EDAC people on how

There was a long thread on it last time, patchkit really is based
on at least some of the sane feedback from that.

But in a nutshell:

This code is quite orthogonal to EDAC: EDAC does enumeration
(or some weird variant of it at least), exporting of counter registers
and some dumping of the registers into the kernel log. 

APEI doesn't do enumeration or counting or registers, it's really just
an interface to retrieve some events from firmware, stop the machine on 
fatal events and pass them on and support managing of the events in a 
backing store.

It's also a standardized interface supported by multiple vendors,
it's not proprietary at all as some people claimed.

> to extend the existing interface, or even work towards creating
> something new that would cater to all interested parties.

Open to serious input. Do you have anything concrete?
Please be concrete and technical ideally with references to code.

Some common comments I heard:

If you want enumeration it could be probably done in some 
EDAC2 variant which fixes the worst problems in the current EDAC interface.
But it won't be talking to APEI directly anyways -- APEI
doesn't do enumeration -- it's really a different problem
and won't be solve by this code.

If you want to move the event channel to perf: we looked at that
and it's not practical with the current infrastructure. And
not a very good fit anyways because the requirements
as quite different from the ones perf was designed for.
For more details see the big thread on the previous posting.

If you want to move the backing store to a file system
or MTD: we actually looked at that too but there were too
many problems and it's really far too much code for the simple 
use case.

Short term this code just attempts to handle fatal chipset errors
(which are a long standing problem in Linux) in a sane way.

-Andi

-- 
ak@xxxxxxxxxxxxxxx -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/