From owner-freebsd-hackers Mon Nov 10 02:07:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA19327 for hackers-outgoing; Mon, 10 Nov 1997 02:07:07 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from bugs.us.dell.com (bugs.us.dell.com [143.166.169.147]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id CAA19317 for ; Mon, 10 Nov 1997 02:07:03 -0800 (PST) (envelope-from tony@dell.com) Received: from ant.us.dell.com (ant.us.dell.com [143.166.12.34]) by bugs.us.dell.com (8.6.12/8.6.12) with SMTP id EAA18326; Mon, 10 Nov 1997 04:00:56 -0600 Message-Id: <3.0.3.32.19971110034659.0069e370@bugs.us.dell.com> X-Sender: tony@bugs.us.dell.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Mon, 10 Nov 1997 03:46:59 -0600 To: Terry Lambert From: Tony Overfield Subject: Re: >64MB Cc: hackers@FreeBSD.ORG In-Reply-To: <199711070052.RAA19368@usr01.primenet.com> References: <3.0.3.32.19971106150448.006d5438@bugs.us.dell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 12:52 AM 11/7/97 +0000, Terry Lambert wrote: >> I think [protected/real-mode instead of vm86 mode] is easier and much >> better for compatibility while booting. > >I don't understand how it's a compatability win. I said this mainly because I think simpler code usually works better. There's also a small chance that you'll run into something that doesn't like vm86() mode. If you're careful enough, this risk isn't worth worrying too much about, after all EMM386 and the others do work ok. Of course, EMM386 and etc., have endured numerous releases to fix this strange bug or that strange bug, that I'm sure nobody expected before it happened. ;-) >Plus there's still the issue of "what INT 13 disk maps to what controller >and target", that's the reason we can't know the BIOS geometry to make >up good fdisk data in the first place... Yes, I know. >Plus we need a VM86() in general in any case, since we may need to call >the BIOS mode setting code for standard PCI/EISA/ISA video cards that >are plugged into non-Intel hardware, etc., because card vendors don't >know how to write data dependencies in a seperate area of their BIOS >so a non-Intel OS could figure out how to program the card without >needing information obtained under non-disclosure. I honestly don't have the time to debate every topic you can think of, interesting though they may be. I entered this discussion by pointing to a problem related to the way in which the kernel reads certain CMOS locations, but it has wandered off into protected-mode-only bootloaders, run-time vm86() BIOS calls, vm86() device I/O port snooping, and something called VM86() that a non-Intel CPU can call that runs x86 video card firmware. To their credit, the non-Intel system designers are taking advantage of the abundance of Intel compatible devices and now you want to complain that the Intel compatible industry should have spent more energy accomodating the other .5% (wild, irresponsible guess) of the market, but they didn't do it because they "don't know how." I don't suppose you can think of any other reason besides that one. - Tony