vm86 in kernel [was: vesafb...]

[Kendall Bennett]

Alan Cox <alan en lxorguk.ukuu.org.uk> wrote:

> > > limitation on using the vm86 services in the kernel from another part 
> > > of the kernel directly (as opposed to from a user space app)? 
> > 
> > This is what I hoped for originally but according to Alan Cox was hackish
> > or unsuitable. I don't know about the details.
> 
> The big problem with putting BIOS code into the kernel is it can
> do a lot more harm there. In a user process the BIOS code can be a
> bit more constrained on the I/O ports you let it loose with and its
> ability to hit physical kernel pages you dont expect. Now it simply
> COW's some zero pages and does no harm. 

Sure, but you can easily ensure that the BIOS can't harm memory you 
don't want it to touch, because the code is all real mode code and 
you can manage the memory that it is mapped into.

Another alternative would be to use a BIOS emulator such as x86emu to 
run the BIOS functions, and then you can have complete control over 
what the code does. We already do this for support under OS'es like 
OS/2 where there is no support for accessing the BIOS (and XFree86 is 
now using this code to POST multiple controllers).

> Its a containment thing.

I suppose if the user land daemon is not such a bad idea, provided 
that everything can be done from the user land daemon that needs to 
be done. In fact I kind of like the idea.

So now that this has been brought up, why can't a user land daemon 
type thing be used to implement accelerated fbdev type functionality? 
Then all you would need in the kernel is a base driver of some 
description to get the card into graphics mode (or even the BIOS 
could be used for that), and all the complex stuff (acceleration etc) 
can be handled by the user land daemon. 

Or better yet, have the system boot up initially in hardware text 
mode (assuming VGA text mode is available), and then switch into 
graphics mode when the user land deamon initialises? Then *all* the 
complex stuff can be offloaded to the user land deamon, and the only 
stuff remaining in the kernel would be the hooks to link it all 
together. 

BTW, if the developer of this code is interested, we have tons of 
source code showing how to properly program the VESA VBE BIOS that we 
have developed over the years (shipped in tons of commercial apps and 
games). I am more than willing to re-license code portions under GPL 
for kernel use if desired (since I wrote all the code I can do that 
;-)

Regards,

+---------------------------------------------------------------+
|   SciTech Software - Building Truly Plug'n'Play Software!     |
+---------------------------------------------------------------+
| Kendall Bennett          | Email: KendallB en scitechsoft.com    |
| Director of Engineering  | Phone: (530) 894 8400              |
| SciTech Software, Inc.   | Fax  : (530) 894 9069              |
| 505 Wall Street          | ftp  : ftp.scitechsoft.com         |
| Chico, CA 95928, USA     | www  : http://www.scitechsoft.com  |
+---------------------------------------------------------------+


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