On Mon, 2013-08-19 at 10:38 -0700, James Bottomley wrote: > It's not about us removing the code, it's about us having an accurate > compliance test. There are two reasons for having a fully correct > compliance test > > 1. Our work arounds have unintended consequences which have knock > on effects which mean that you don't know if a test failure is > real or an unintended consequence of a work around. > 2. New features in specs tend to build on previous features, so > we're going to have a hard time constructing accurate tests for > layered features where we've done a work around for the base > feature. 3. Even if we can't *remove* the code, sometimes we can disable it at runtime if we detect the BIOS is new enough that it shouldn't be broken. Do we really want to declare that we can only use 50% of the available NV storage space for *ever* more, just because some muppet thought they could squeeze some non-upstream "value add" into their implementation of the flash management? You seem to be suggesting that we should retrospectively write that limitation into the UEFI spec, which is a completely insane suggestion. We absolutely want to be able to draw a line under it and declare that any firmware built after $SOMEDATE is expected to be fixed, so we don't have to do these stupid workarounds, and we can make full use of the available space. This type of model gets used for Windows all the time, doesn't it? Especially with ACPI, they base some of their behaviour on the date that the BIOS claims to be built, and only use newer features if it's new enough that they're expected to be working? 4. We don't want people turning up to a plugfest with a buggy pile of crap that we just *happen* to have worked around already, and going back to their company with a happy "no problems discovered" report, and thinking that they are doing a good job. If they turn up with a buggy pile of crap, we want to make sure they *know* it's a buggy pile of crap — they need to be sent home with their tail between their legs with a clear message that they need to do better in future. And that will *help* to avoid future bugs, hopefully. The point of a plugfest is *not* just to gather a torture test together and force the kernel developers to find a consistent set of workarounds for *every* pathological brokenness out there. We could do that with a big credit card and a buying spree of random machines. Of *course* we should also do the tests with a fully-workarounded kernel and be able to ensure that our kernel can boot on existing machines. But that's a separate issue. That's about *us* learning and improving. But it does need to work *both* ways for all parties to get the maximum benefit. -- dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
