Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 4 Jan 1996 13:43:14 +1030 (CST)
From:      Michael Smith <msmith@atrad.adelaide.edu.au>
To:        terry@lambert.org (Terry Lambert)
Cc:        msmith@atrad.adelaide.edu.au, terry@lambert.org, jdl@jdl.com, jkh@time.cdrom.com, obrien@cs.ucdavis.edu, freebsd-hackers@freebsd.org
Subject:   Re: X for install
Message-ID:  <199601040313.NAA09827@genesis.atrad.adelaide.edu.au>
In-Reply-To: <199601040159.SAA16479@phaeton.artisoft.com> from "Terry Lambert" at Jan 3, 96 06:59:46 pm

next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert stands accused of saying:
> > Ok Terry, you win.  VM86() it is; now can you or one of the other VM
> > wizards dribble enough of it out so that we can set up a context in
> > which it is safe to make BIOS calls? 
> 
> Well, this didn't *necessarily* need a VM86().  But that *is* one
> soloution... I was thinking on the lines of a weenie DOS program
> to blow the 32 bit offsets in the partition table before install.

We need an awful lot more than that.  While probing for disks and other
devices, we need a BIOS disk driver that can read the root filesystem
and suck in LKMs, including the disk drivers.  Eventually, / would be
remounted from another device, and the now-loaded 'real' disk drivers
would come into play if they could, or the BIOS fallback driver would
continue to carry the load.

> the ideal candidate.  8-)  8-).  I have someone else who I'd nominate,
> since he has been all over the Win95 VM system very recently, but he'd
> probably kill me for it...

You could do with a good killing, so I suggest you nominate away. 8)

> They had a VM86() mode working well enough for DOSEMU.  This is not
> quite enough for a "call this BIOS call on my behalf in a Virtual 8086
> machine that prevents kernel reentrancy, please".  Which is really what
> needs to be done, unless you dick with the DOS stack for the low INT
> calls (there's a nice TSR book that describes doing exactly this with
> Borland Turbo C).

I'm not going to try to define "what needs to be done" at that level; I'm
suggesting that you & several other people know what needs to be done,
and I'm just prodding at you until you do it.  Hint? 8)

> Actually, you *don't* want video BIOS for anything more than mode
> setting.  Most VGA cards that emulate EGA and CGA registers (Paradise,
> etc.) disable interrrupts instead of waiting for the vertical blank
> interrupt to handle screen draws.  A no-no if you have active serial
> ports or a network card, floppy tape, etc.

Point.  Video hardware is sufficiently standard that BIOS support's not
a great win except maybe for VESA BIOS operations, and they're not terribly
standard.

> 					Terry Lambert

-- 
]] Mike Smith, Software Engineer        msmith@atrad.adelaide.edu.au    [[
]] Genesis Software                     genesis@atrad.adelaide.edu.au   [[
]] High-speed data acquisition and      (GSM mobile) 0411-222-496       [[
]] realtime instrument control          (ph/fax)  +61-8-267-3039        [[
]] "Who does BSD?" "We do Chucky, we do."                               [[



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