From: jwaters@deepthought.unm.edu (Joe Waters) Subject: Re: inb/outb babble.. was Re: Problem with inb and outb.. Date: 15 Jun 1992 22:49:04 GMT
In article <1992Jun15.125504.7083@wam.umd.edu> joel@wam.umd.edu (Joel M. Hoffman) writes:
>Heheh.. Yes, a friend and I realize that this will probably defeat the
>purpose of Linux, but we're stubborn. I want it to run WWIV. that's
>the only program I have any need of from DOS. also need Turbo C to keep
>WWIV happy. these programs both requre heavy port io. anyway, this
>is the end goal I'm working towards. for ports that really destroy Linux,
> If it's not too hard, I would suggest two compile-time options, one
> with direct port access by the vm86 process, and the other with
> emulation. Emulation is a MUCH better solution for many reasons. One
> that comes to mind is that more than one vm86 process can run at a
> time. The other, already stated, is that it won't compromise system
> integr{ty.
I (being Techs' friend) was planning something similar. Instead of
making it a compile-time option, it would be a runtime option such as issuing
the command "dosemu -P" which would put the emulator into a sort of protected
mode that traps most i/o port calls and emulates what it can. Of course,
emulation would be a better way to go; the main problem is that there are
0xFFF ports which DOS programs call any time they feel like it. There will
probably be three modes which the thing can operate in: 1) emulation-only of
whatever we can make emulatable, 2) full I/O access (which will essentially
turn Linux into a DOS box until you shut down the emulator with a reboot
command, at which point Linux will return to the land of the living (this
part already works), and 3) the "protected" mode, where the code emulates
everything which will blow up Linux (reading the keyboard directly, serial
ports (hopefully with lockfiles - I'll look at that in the next few days),
etc, while letting some non-dangerous I/O calls (stuff to the game port, for
example) through, and finally LOCKING COMPLETELY OUT some I/O calls (like stuff
that directly accesses DMA, the HD controller, etc)... This should make
just about everybody happy, and the full I/O access option will be "run at
your own risk"...
>My friends's goal is to hack the kernel to allow switching between graphics
>consoles so that he can run X on one console and GeoWorks under the dos
>emulator. ;-) It'll be a cool hack if it works. so will the port stuff,
>i think.
> CMU's Dos emulator has code for completely saving and restoring the
> state of the VGA card. You might want to look at it.
> -Joel
I know -- I've already taken a look at that code... Anything with
saving/reloading the entire VGA card when you switch VCs is a way off though --
we're going to get the simpler stuff working better first (like color for the
text mode which is going to require a major rewrite of the direct screen
access stuff)... Things are moving though.
Joe