> Why is it ugly? IMHO it is very much needed, as it would provide a
> mechanism for the kernel to be able to properly restore the screen
> if a user land program goes astray.
First - the bios isn't always able to fix the screen - the program may
have programmed the video hardware in odd ways the bios don't know
about. Bioses aren't a magic fix.
Second, the proper way to do this is for the video driver to fix it up,
using more efficient code that runs under linux without special
consideration because it was written for that case.
> More tricks like what? All we need is the ability to call the BIOS and
> have it execute the necessary real mode code, just like we do on ia32
> machines in user land.
Ability to call the bios in real mode is no simple feat. And the bios
may screw up. That doesn't matter for a user program, it just crashes
and don't damage anything else. You don't want the kernel to crash -
ever. A broken bios is _no_ excuse here.
Bioses are generally too limited. They make a lot of stupid
assumptions, thinking it is ok to use legacy vga registers and things
like that. Consider a machine with two or more video cards. Linux
handles that fine, but a bios? Or really two bioses, one for each card?
Imagine a dual processor where one one processor executes one bios and
the other processor another bios , each trying to set up one card.
Somehow I think this won't work too well.
As for userspace tricks - userspace can do all sorts of nifty things
like actually open a file and read it. For example a file
with the latest list of bios oddities to work around.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/