lkml.org 
[lkml]   [2013]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [regression, bisected] x86: efi: Pass boot services variable info to runtime code

* Borislav Petkov <bp@alien8.de> wrote:

> On Fri, May 31, 2013 at 01:06:09PM +0200, Jiri Kosina wrote:
> >
> > (*) If one would be naive enough, he'd believe that the pressure
> > should be put on the BIOS writers instead of OS to fix the bug :)
>
> Oh, definitely pressure on BIOS dudes. If they're in violation of the
> spec and they still can fix it in time, they better. I'm sick and tired
> of having to deal with BIOS idiocy in kernel code.

I'm all for some BIOS quality bashing, but the reality is:

1) It's not just about SGI/UV systems but apparently about several
different types of x86 laptops produce the same boot crash pattern:
most of which come from manufacturers that simply don't care about
Linux all that much.

So by not reverting we'd screw our users, not put any recognizable
pressure on any BIOS writers or manufacturers.

2) Obviously Windows does not crash, and that's what most laptops test.
So our realistic 'spec target' is not some sort of pure 'EFI spec',
but EFI implementations _tested under Windows_. Consider it an
'extended EFI compatibility spec'.

3) There's a better, more robust firmware environment approach being
worked on (by you?) that avoids such 1:1 physical mapping assumption
crashes. That's something worth doing anyway, so why not delay the
early QueryVariableInfo() call change to when that enviroment is
properly implemented?

4) The revert is easy, and the functionality the original patch provided
was a marginal increase in debug output to begin with...

So to me the right approach seems to be:

A: revert now for v3.10
B: implement 1:1 mappings environment for firmware, for v3.11
C: reintroduce the early QueryVariableInfo() call again, in v3.11

Thanks,

Ingo


\
 
 \ /
  Last update: 2013-05-31 15:21    [W:0.826 / U:0.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site