Date: Sun, 31 Aug 1997 21:14:39 -0700 From: Jonathan Mini <j_mini@efn.org> To: Mike Smith <mike@smith.net.au> Cc: 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: <19970831211438.52861@micron.efn.org> In-Reply-To: <199709010239.MAA00384@word.smith.net.au>; from Mike Smith on Mon, Sep 01, 1997 at 12:09:21PM %2B0930 References: <19970812195034.31150@right.PCS> <199709010239.MAA00384@word.smith.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith stands accused of saying : > In most cases, I see this interface being used by other kernel services > to interact with BIOS functionality that's not available otherwise. > Off the top of my head, the big consumers are likely to be : > > - Video control; access to the full set of VESA functionality > - Resource management (especially the ECSD parameter space) VESA is big on my list. The main reason I want this support is that I am making a version of the FreeBSD kernel which will execute as a DPMI application. My final goal is that a user will be able to open a DOS box in his Win95 (or similar) desktop machine and run my application. My 'application' will act as an extender for a copy of my perverted FreeBSD kernel which will then run the proper process as init. In the meantime, I have a lot of work ahead of me. My first step is to make "devices" that use the BIOS and other similar blocks of code (such as Win95) in order to do common things such as access the hard drive(s), etc. My first milestone will be to have a kernel which will use the BIOS for all disk i/o. > I would, I guess, like to be able to say : > > - create vm86 context foo with memory size X, default layout, etc. > - populate specific components of X > - invoke <some functionality> in vm86 context foo > - access X > - destroy vm86 context foo > > At the bare minimum, the context should comprise the address space the > vm86 thread has access to, the register state, I/O permissions, etc. > It should be possible to copy code into the address space, or to > request a set of "canned" operations. Perhaps pseudocode speaks this > better : > > foo = vm86_create_context(64 * 1024, VM86_NOIOPERM, ...); > VM86_INIT(foo); > VM86_REG(foo, cx, 0x35); > VM86_INTR(foo, 0x10, 0x55, 0x01); > VM86_TERMINATE(foo); > vm86_run_context(foo, ...); > > 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, 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) 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) > > My current thinking (for the kernel) is: > > > > - create a 'vm86daemon', which maps in the lower physical 1M into > > it's address space. > > Hmm. With the idea above, you would map the memory region belonging to > the context at the bottom of the address space, and the ISA hole > suitably, and leave most of the rest unmapped. I don't think too many > callers will need an entire 1M mapped. Better to create a mappign for each instance, because that way you can "map" sections of code into the region when you need it. Mapping an entire 640k block would be a Bad Idea, since it eats a good chunk of physical memory from VM space. > > - submit requests to this thread, which puts the caller to sleep > > until the request completes. > > 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. > > Am I on the right track here, or am I totally off base? > > Sounds pretty groovy to me! > > mike > -- Jonathan Mini (j_mini@efn.org) Ingenious Productions Software Development P.O. Box 5693 Eugene, Or 97405
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970831211438.52861>