Re: UEFI Plugfest 2013 -- New Orleans

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 2839 bytes --]

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 #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5745 bytes --]