uk.comp.os.linux
[Top] [All Lists]

Re: Don't buy Foxcon Mboards being sold with dodgy BIOS

Subject: Re: Don't buy Foxcon Mboards being sold with dodgy BIOS
From: Nix <nix-razor-pit@xxxxxxxxxxxxx>
Date: Sun, 27 Jul 2008 16:19:27 +0100
Newsgroups: uk.comp.os.linux, uk.comp.homebuilt, 24hoursupport.helpdesk

On 26 Jul 2008, Conor verbalised:

> In article <Rc-dneAF9umxxxbVnZ2dneKdnZydnZ2d@xxxxxxxxx>, Big and Blue 
> says...
>> §ñühwØ£f wrote:
>> 
>> > Theres a hack for Grub that tells the mobo its runniing windoze.
>> 
>> Which, to me at least, indicates that the problem lies in the 
>> motherboard.  The motherboard shouldn't need to know what OS is running. 
>
> How the fuck does the motherboard know what OS it's running, dumbass?

It asks the OS via the _OSI predefined object. (ACPI does after all
involve the operating system executing BIOS-provided AML code via an
interpreter which is *part* of the operating system. This isn't like
SMIs: the OS maintains control.)

(A tiny little bit of research in the topic you're arguing in wouldn't
go amiss. A couple of quick searches showed me pages 172--173 of
<http://www.acpi.info/DOWNLOADS/ACPIspec30a.pdf> (labelled 154--155)
which plainly describe this interface. This took me less than a minute
to find, and anyone else who can use Google could have done the same.)


Unfortunately the interface isn't much use as specified there. Nothing,
not even Linux, returns true for _OSI("Linux"), because what would it
mean? Different versions of the Linux kernel have different bugs and
different capabilities in regard to hardware interaction. So Linux
pretends to be Windows via _OSI and has to emulate its bugs.

There is discussion of ways to get around this, because it's plainly
inelegant to have to emulate Windows's hardware-interaction bugs, but
nothing firm has resulted yet. The _OSI interface is probably broken: we
really need feature-test macros instead. However, even that is fraught
with problems, because vendors can't very well add a macro that states
that they have, or don't have, a bug before the bug is known. So we'd
need at least three states: we have this bug/feature, we don't have it,
and we don't know: and then there'd be bugs when BIOSes interpreted
`we don't know' in an unwise manner... this is a nest of snakes, and
it is definitely not a sign of dumbassery to find the whole thing
thoroughly confusing.

<Prev in Thread] Current Thread [Next in Thread>