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-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
