What you appear to be arguing for is the ability to inject different types of
events.
_OF COURSE_ we want that.
Just like we want to be able to _receive_ multiple types of events from wildly
different hardware and wildly different kernel subsystems ...
Duh.
That desire does not necessiate 'three different injectors' at all. It does not
necessiate multiple incompatible facilities with random ABIs.
What we want is a single injector facility visible to RAS/hw-testing/etc. apps, and
a way to pass in attributes that specify the kind of event that we want to trigger.
Also note that you completely ignored the other basis of my objection and NAK: that
the whole ad-hoc event log export that this code does via the /dev/erst-dbg ABI is
actively harmful.
Everyone else working on this area thinks it's realistic, and is in fact working on
such a facility.
The main thing that is causing confusion here is not the technical viability of such
a project (it's evidently doable and desirable), but your unwillingness to
cooperate. If Intel goes into random directions and essentially obstructs upstream
projects then we wont have this implemented on Intel CPUs sanely and cleanly -
despite Mauro's best efforts on the Nehalem code.
But you should really not bring that up as some kind of positive argument ...
Thanks,
Ingo
--
