Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 01 Sep 1997 14:11:57 +0930
From:      Mike Smith <mike@smith.net.au>
To:        Jonathan Mini <j_mini@efn.org>
Cc:        Mike Smith <mike@smith.net.au>, Jonathan Lemon <jlemon@americantv.com>, =?iso-8859-1?Q?S=F8ren_Schmidt?= <sos@sos.freebsd.dk>, karpen@ocean.campus.luth.se, hfwirth@ping.at, emulation@FreeBSD.ORG
Subject:   Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD) 
Message-ID:  <199709010441.OAA00750@word.smith.net.au>
In-Reply-To: Your message of "Sun, 31 Aug 1997 21:14:39 MST." <19970831211438.52861@micron.efn.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
> > ie. create a context, initialise it for code insertion, insert code to
> > set %cx to 0x35, insert code to call INT 0x10 major function 0x55 minor
> > function 0x01, insert code to terminate the context, and then run the 
> > code in it.  It might be desirable to supply some form of time limit in 
> > the run_context function to trap runaway invocations; that's probably 
> > fluff though.  Being able to run it in parallel, and query it for 
> > status rather than blocking until it completes would be _very_ useful, 
> > as I'm sure you can imagine 8)
> 
>   Hmm. What I had in mind was something similar to a micro-kernel approach,
> where a vm86 context would be created, the proper memory addesses mapped into
> it, and then a piece of real mode code would be copies (or mapped) into the
> context, and the kernel would manage several pages of code to do various
> things.  IMO, this seems to be more efficient than above, 

The approach I proposed certainly doesn't preclude copying your own 
slab of code into the vm86 context; I was just proposing that in 
addition to that, there should be some macros which know how to append 
trivial code fragments in order to make writing and reading such 
callers easier.

> however, unless
> FreeBSD gets a version of gcc to output real mode code, my method dies in
> flames. (I have access to several real mode compilers, but they are all
> comemrcial) 

ports/devel/bcc

>   I know that a real mode version of gcc is possible -- Minix uses gcc, and it
> runs under Real mode. (Minix/386 doesn't, but the XT version does)

You are mistaken.  The Minix cc for the x86 is *not* gcc.  gcc is 
available for the 68k and i386 Minices however.

> > I would be inclined to try to support more than one vm86 thread at 
> > once, with the possibility of asynch execution and notification (or 
> > even just blatant status polling).
> 
>   I would like to have that supprot also, but rember that the BIOS
> specification is not re-entrant, and I know of a lot of BIOSes (and BIOS
> emulators) that will crash if reentrance is attempted.

It certainly makes no sense to attempt to reenter the video BIOS, but 
in at least the trivial sense there is nothing stopping me calling, 
say, an ESCD function in one virtual x86 context while the video BIOS 
is being called in another; remember that they are operating in 
distinct virtual contexts, where the only risk of conflict is in the
I/O domain.

mike





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709010441.OAA00750>