* Andi Kleen <andi@xxxxxxxxxxxxxx> 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. That's my whole point, _why_ do they have different interfaces? EDAC is the upstream mechanism to organize hardware error reporting and to get hardware errors to user-space. It is already successful in handling a wide range of hardware in a similar fashion. Furthermore, there is work ongoing to do the reporting via perf event channels, some of that work is upstream already. Boris is working on persistent events, on RAS tooling (tools/ras/) and on event injection. Here's a past submission of his work: http://lwn.net/Articles/394522/ You are now doing a completely separate thing here, detaching a big CPU vendor from the main body of Linux code that deals with this stuff. IMHO that's not helpful _at all_. > > > einj.c: it's about the 3rd separate 'error injection' concept that got > > > introduced ... > > > > EINJ is a true platform feature, not just software feature. We need to support > > it to debug various hardware error features. > > Also having multiple error injecting interfaces is a good thing. It's never a good thing to have separate, vendor dependent interfaces for what to the user is basically the same conceptual thing! > Error injection is hard and one size definitely doesn't fit all. You need quite > different ones depending on what you want to test, in which context etc. And that kind of variance is in your opinion a good reason to introduce separate user ABIs for it? ( And i dont care that there might be no 'end user' for hardware error injection per se right now. There is certainly an 'end user' for hardware error events and even _there_ you are introducing and pushing for separate, incompatible interfaces. ) We have really good historic data here: we got the _biggest_ practical advantage from event enumeration (/debug/tracing/events/) when we extended it in a generic, unified way to the rich topology that the hardware and the kernel gives us. That way we got new, useful tools like powertop, timechart or pytimechart or the edac tool, which can concentrate on a single, well-defined event topology and event ABI. Why do these tools like this kind of unified event enumeration and reporting facilities, which you are fighting against so hard? Because of the big technological advantage of having to deal with one enumeration and reporting facility alone. They can get power events, scheduling events, timer events, kmalloc events all from the same source - even though these subsystems have barely anything in common! Tools can then combine these seemingly unrelated events into something new and useful. It's a very extensible model, and with every new event type added, the tool space gets richer _together_. Error event injection to simulate/trigger various error conditions in those events is a natural extension to the whole events framework - not something that should be in a randomly different way. What you are doing here is to fragment the whole landscape into small, incompatible, vendor specific bits. Some of it is in /dev, some of it is in debugfs, some things report via signals, etc. etc. It's inconsistent, messy and doesnt integrate well with the events framework we are building. That was the main basis of my prior NAK, and you have said _nothing_ in the past that invalidates the fundamental points of that NAK. Instead you started, by stealth and by duplicity, looking for ways to get around that conceptual NAK. > For hwpoison we currently have three different injectors at least and I expect > that to even grow more in the future as different features get added. That's insane! Ingo -- 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
