On Mon, 19 Aug, at 09:09:54PM, David Woodhouse wrote:
> 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.
Yes, this is definitely something we should be looking to implement.
It seems likely to me that
On Mon, Aug 19, 2013 at 10:06:51PM +0100, David Woodhouse wrote:
> You effectively seem to be suggesting that nothing will ever get better
> on the UEFI side, and the only benefit of the plugfest is that we get to
> see the latest brokenness and try to come up with a workaround for it
> before the
On Mon, 2013-08-19 at 21:39 +0100, Matthew Garrett wrote:
> The plugfests have, from our perspective, always been useful in
> identifying new implementation interpretations before hardware ships.
> But even then, it's usually too late to modify the firmware. Vendors who
> care about Linux compat
On Mon, Aug 19, 2013 at 09:21:11PM +0100, David Woodhouse wrote:
> On Mon, 2013-08-19 at 21:19 +0100, Matthew Garrett wrote:
> >
> > We have no way to guarantee that. Most board vendors don't turn up to
> > the plugfests and aren't going to run anything we ship.
>
> Oh well, let's just wring our
On Mon, 2013-08-19 at 21:19 +0100, Matthew Garrett wrote:
>
> We have no way to guarantee that. Most board vendors don't turn up to
> the plugfests and aren't going to run anything we ship.
Oh well, let's just wring our hands and not bother to turn up to the
plugfest at all then. No point trying
On Mon, Aug 19, 2013 at 09:09:54PM +0100, David Woodhouse wrote:
> 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
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 Mon, Aug 19, 2013 at 10:38:46AM -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 knoc
On Mon, 2013-08-19 at 18:21 +0100, Matthew Garrett wrote:
> On Mon, Aug 19, 2013 at 10:02:55AM -0700, James Bottomley wrote:
>
> > The object of having a test suite conform to the spec is not to
> > perpetuate the cockups that occurred in round one of the implementation
> > and to force everyone t
On Mon, Aug 19, 2013 at 10:02:55AM -0700, James Bottomley wrote:
> The object of having a test suite conform to the spec is not to
> perpetuate the cockups that occurred in round one of the implementation
> and to force everyone to pay closer attention to what the spec says.
> Otherwise the amount
On Mon, 2013-08-19 at 17:00 +0100, Matthew Garrett wrote:
> On Mon, Aug 19, 2013 at 08:22:45AM -0700, James Bottomley wrote:
> > On Mon, 2013-08-19 at 13:55 +0100, Matthew Garrett wrote:
> > > On Mon, Aug 19, 2013 at 09:25:35AM +0100, David Woodhouse wrote:
> > >
> > > > Every deviation from the s
On Mon, Aug 19, 2013 at 08:22:45AM -0700, James Bottomley wrote:
> On Mon, 2013-08-19 at 13:55 +0100, Matthew Garrett wrote:
> > On Mon, Aug 19, 2013 at 09:25:35AM +0100, David Woodhouse wrote:
> >
> > > Every deviation from the spec (or common sense), however minor, should
> > > show up as a clea
On Mon, 2013-08-19 at 13:55 +0100, Matthew Garrett wrote:
> On Mon, Aug 19, 2013 at 09:25:35AM +0100, David Woodhouse wrote:
>
> > Every deviation from the spec (or common sense), however minor, should
> > show up as a clear failure. Even the ones we *have* been able to work
> > around, because we
On Mon, Aug 19, 2013 at 09:25:35AM +0100, David Woodhouse wrote:
> Hm. It would be really useful to have a kernel build option which
> *disables* all the workarounds we've ever put in for broken firmware.
Yeah, cool!
I wonder if we could reach a high double-digit percentage of machines
not bootin
On Mon, Aug 19, 2013 at 09:25:35AM +0100, David Woodhouse wrote:
> Every deviation from the spec (or common sense), however minor, should
> show up as a clear failure. Even the ones we *have* been able to work
> around, because we still want them *fixed*.
Why? It's not like we can ever stop carry
On Fri, 2013-08-16 at 11:20 -0400, John W. Linville wrote:
> All,
>
> The Linux Foundation and The UEFI Forum are hosting a UEFI Plugfest
> event in New Orleans on September 19-20, 2013. This event will run
> concurrent with Linux Plumbers Conference, just after LinuxCon at the
> Hyatt Regency Ne
On Fri, 2013-08-16 at 11:20 -0400, John W. Linville wrote:
> Participants in this event must join the UEFI at the Adopter level or
> above (gratis):
>
> http://www.uefi.org/join
Just a note on doing this. I did it today using the three page form on
the uefi web page: you can fill it in on
All,
The Linux Foundation and The UEFI Forum are hosting a UEFI Plugfest
event in New Orleans on September 19-20, 2013. This event will run
concurrent with Linux Plumbers Conference, just after LinuxCon at the
Hyatt Regency New Orleans.
This event is intended to provide the Linux community with
18 matches
Mail list logo
