Messages in this thread | | | Date | Tue, 6 Dec 2005 15:25:46 -0800 | From | Andrew Grover <> | Subject | Re: Linux in a binary world... a doomsday scenario |
| |
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/
| |