Re: Linux in a binary world... a doomsday scenario

[Andrew Grover <andy.grover@gmail.com>]

On 12/6/05, David Woodhouse <dwmw2@infradead.org> wrote:
> On Tue, 2005-12-06 at 19:23 +0000, Alan Cox wrote:
> > On Maw, 2005-12-06 at 18:42 +0000, David Woodhouse wrote:
> > > There's some work on reverse-engineering the BIOS so that you can
> > > hackishly poke 'new' modes into its tables, but it's still not a very
> > > good option.
> >
> > Especially as the BIOS interface at the low level for the analogue end
> > and the logic driving it is board specific. Intel have been fairly clear
> > why they use the BIOS interface.
>
> Have they? I haven't seen the excuse.
>
> I assume it's similar to the excuse for ACPI -- "although we _could_
> document the chips and allow board manufacturers to include simple
> tables which describe the way they're wired together (in which they have
> relatively little leeway), we'd rather hide it all behind some opaque
> blob and have you trust HardwareVendorCode to drive it instead of being
> able to write your own and debug it as you can with Free Software"?

Where possible ACPI does still use tables. For more complicated
configuration, ACPI uses easily-decompiled bytecodes. I think if the
graphics bios provided arch-neutral AML for doing all this
mode-setting stuff we'd be better off. Better than interpreting x86
real-mode BIOS code!

> Trusting the BIOS for this kind of thing isn't really much better than
> trusting any other binary-only piece of code, from a technical point of
> view. (Ignoring the licensing issues; we have indeed digressed). In
> fact, given the traditional quality of BIOS implementations, trusting
> the BIOS is far _worse_ than trusting any other piece of binary code.

You have to get a priori information about the system somewhere. With
ACPI at least it's not a complete mystery what the BIOS is doing,
unlike these video BIOSes.

-- Andy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/