Matthew Garrett

I don't agree with your assertion that " Windows 8" is a contract. "contract" implies something formal and well-defined. What happens in the real world is windows starts doing things one way, which may or may not be spec compliant. When we vendors make a new piece of hardware, we adjust our ACPI tables until windows stops bluescreening. It really is this brute-force approach. ACPI tables end up becoming bad hacks to work around bad programming in windows. If the end-user doesn't notice something's wrong, the attitude of most vendors is to say it's not wrong. In my line of work I don't have the luxury of bad hacks when it comes to firmware. In early development, I can get away with booting linux without a BIOS or EFI interface. I am incredibly lucky to be allowed to do this, as linux will complain loudly about mistakes in ACPI. Once linux shuts up, then we move on to windows testing. Notice that at no point do we care if we're ACPI compliant. ACPI compliance is so ill defined, that even if we cared, there would be no way to verify if we are indeed compliant. If you want to get to the heart of the problem, stop being part of it. Stop being part of the RedHat-Linaro-Intel-Microsoft complex which pushes these ill-defined and unduly complex specifications. Notice that, in order to run an OS that can fully utilize the features of the hardware, we haven't truly needed BIOS calls for a long while, and we don't need EFI if we can correctly implement a very limited subset of ACPI. And once you've reduced everything to this simplest scenario, you realize that what's left is just a misdefined devicetree. Linux on ARM and a few other non-x86 architectures has been doing just fine with a proper devicetree. Why we're still talking about thousand plus page firmware interface specifications is beyond me. Everything EFI does and does not do can be done by firmware in a hardware-direct manner, with less layers and less complexity. On ARM that firmware is really damn simple. As soon as we bring in EFI and ACPI complexities to this ARM firmware, we'll run into the same set of problems we're having today on x86. An unrelated point: when you talk about firmware relying on undefined behavior, you're talking about bad programming. You make it sound like you condone this reliance on the undefined, and by induction, that you condone bad programming. I'm certain that's not what you meant.