Alan Cox <alan@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@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@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:14 EST