From owner-freebsd-emulation Tue Aug 12 19:41:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA11877 for emulation-outgoing; Tue, 12 Aug 1997 19:41:00 -0700 (PDT) Received: from micron.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA11858 for ; Tue, 12 Aug 1997 19:40:51 -0700 (PDT) Received: (from mini@localhost) by micron.efn.org (8.8.5/8.8.5) id TAA02131; Tue, 12 Aug 1997 19:40:57 -0700 (PDT) Message-ID: <19970812194056.12566@micron.efn.org> Date: Tue, 12 Aug 1997 19:40:56 -0700 From: Jonathan Mini To: Jonathan Lemon Cc: =?iso-8859-1?Q?S=F8ren_Schmidt?= , karpen@ocean.campus.luth.se, hfwirth@ping.at, emulation@FreeBSD.ORG Subject: Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD) Reply-To: Jonathan Mini References: <19970811114903.20861@micron.efn.org> <199708112025.WAA03492@sos.freebsd.dk> <19970812195034.31150@right.PCS> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.76e In-Reply-To: <19970812195034.31150@right.PCS>; from Jonathan Lemon on Tue, Aug 12, 1997 at 07:50:34PM -0500 X-files: The Truth is Out There. Sender: owner-freebsd-emulation@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jonathan Lemon stands accused of saying : > On Aug 08, 1997 at 10:25:18PM +0200, Søren Schmidt wrote: > > > Hehe. I am working on it, however, you won't get realmode, just something > > > similar -- a v86 thread with the mappings of real mode. It should be close > > > enough :) > > > > As long as it lets me call a 16bit realmode subrutine in the (S)VGA BIOS > > I'll be OK :) > > Amazingly enough, I've been working on something similar too. At this point, > I think I need a little bit of feedback. > > How would a vm86() interface be used? I don't think that just passing in > the i386 registers and an interrupt number to call would be enough; I think > that some of the INT calls want to pass data back and forth via low-memory > areas. > > If that is the case, then the address space has to exist before and after > the call; probably the easiest way would be for the calling process to create > the address space and then pass it to the vm86 thread. Otherwise, the thread > could just attach to kernel area around 'atdevbase' > Also, where would this be called from? kernel code only? user code? > If both, then there should also be a parameter that specifies what I/O the > process is permitted to do. This way, when when calling some arbitrary piece > of BIOS code which may touch I/O space, we can fail if the call was from user > mode. My opinion is that it should be callable from kernel space only. Although, it would be kinda nice to call a BIOS routine from a userland process, my mind makes large comments about security holes. > Side note here: the vm86 changes do permit controlled access to the full > I/O space from user-mode, assuming that the process is running as root. > > My current thinking (for the kernel) is: > > - create a 'vm86daemon', which maps in the lower physical 1M into > it's address space. > > - submit requests to this thread, which puts the caller to sleep > until the request completes. > > Another possibility would be to create a new thread for every call, but > that seems to have too much overhead. No! The BIOS is not re-entrant. The requests must be seriealised, no matter how inefficient it is. > Am I on the right track here, or am I totally off base? > -- > Jonathan -- Jonathan Mini (j_mini@efn.org) ... bleakness ... desolation ... plastic forks ...