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 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 New
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
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
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 still
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 clear failure.
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 spec (or
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 of
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 to pay
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 knock
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 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, 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 hands
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
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 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
16 matches
Mail list logo
