From owner-freebsd-hackers Tue Nov 18 03:24:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA14395 for hackers-outgoing; Tue, 18 Nov 1997 03:24:34 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from d198-232.uoregon.edu (d198-232.uoregon.edu [128.223.198.232]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA14390 for ; Tue, 18 Nov 1997 03:24:30 -0800 (PST) (envelope-from mini@d198-232.uoregon.edu) Received: (from mini@localhost) by d198-232.uoregon.edu (8.8.5/8.8.5) id DAA25156; Tue, 18 Nov 1997 03:23:54 -0800 (PST) Message-ID: <19971118032353.57770@micron.mini.net> Date: Tue, 18 Nov 1997 03:23:53 -0800 From: Jonathan Mini To: Tony Overfield Cc: Jonathan Mini , hackers@freebsd.org Subject: Re: >64MB Reply-To: Jonathan Mini References: <3.0.3.32.19971118043736.006d7d48@bugs.us.dell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <3.0.3.32.19971118043736.006d7d48@bugs.us.dell.com>; from Tony Overfield on Tue, Nov 18, 1997 at 04:37:36AM -0600 X-files: The Truth is Out There Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Tony Overfield stands accused of saying: > At 02:58 AM 11/10/97 -0800, Jonathan Mini wrote: > > 1) The boot blocks are a part of the boot process, meaning that > > they should function in real mode (being part of initializing the > > processor) and the sole function of this code is to load the kernel > > into memory. (this is bogus, IMO) > > Well, I don't think it's bogus, and Terry seems to want this one, if I > haven't mistaken his statements. This has certain ideological advantages > with respect to portability and multiple platform development. Hmm. As I read his reply, he seemed to be a proponent of setting up a vm86 TSS for the real mode code. > > 2) The boot blocks are a small microkernel who's sole purpose is to > > load the main kernel (or possible a second micro-kernel which handles > > config : read three stage boot) into memory and give it control. To > > do this, it needs to have two contexts : > > a) a protected context with mappings for the kernel, and > > b) a vm86 context for talking to the BIOS. > > Yes, this is one possible approach, but I still think it offers no extra > value over what we have now. Please don't assume I don't understand these > issues. Regardless, I don't really care what approach is taken, so long > as it is implemented correctly. Also remember that I'm referring to boot > time code only. I understand, but your second statement eludes me. You say that you don't care what approach is taken, as long as the code is implementd properly? But the approach taken to the solution is half of the implementation. A hack is still a hack, even if it is the most beutiful code within itself. > > The boot blocks shouldn't be constantly hopping from Real Mode to Protected > >Mode over and over again! This is insane, > > No, this is done all the time. Switching between modes is fast, small and > easy (excluding the '286, of course). Whether or not something is 'done all the time' is not an issue, it is still insane. > [ ... snip ... ] > I'm quite familiar with the various things in a BIOS that can break > Windows 95, DOS, QEMM, EMM386, etc. Real mode has PE=0, so code that > wants to hijack the processor state can know that "ring 0 run state" > is irrelevant. I did say that I knew of no BIOS that does this, but > it is possible, without breaking any of the programs you mentioned, > except for, possibly, the "big limits" code which started all of this. Then you should know that Win 95, QEMM, EMM386, and OS/2 (to name a few) run the processor in a vm86 task the whole time, to maintain their virtual memory mappings. (and EMS emulation) -- even when calling the BIOS. > Fortunately, there's nothing to be gained by adding "big limits" code > into a bootloader, so that whole discussion is tangential, unnecessary, > and uninteresting. In essence, you are right. This discussion is besides the point, and boring. Whether or not anything would be gained was the topic of debate, so I have to disagree. I would come up with convincing evidence, but I prefer to drop this debate. > BTW, I assume the "spec" that you speak of is the defacto (and > imaginary) "must run all code without bugs" spec that I am forced > to use (among the many others that do exist). ;-) Yes and no. THe 'spec' I speak of is from several specifications, which all boil down to the fact that once the BIOS gives the processor to the OS, it doesn't get to play hanky-panky with the machine state. > [ ... snip ... ] > >> I simply don't believe 1) that the booloader does enough of these to > >> matter, and 2) that anyone really cares about the performance of code > >> that runs for less than one second per boot (on my systems, at least). > >> On every system I've seen, the bootloader spends most of that second > >> either waiting for I/O, or doing I/O. > > > > The point isn't really performance, but rather that we should be running in > >protected mode ASAP. Especially since we don't have a 16bit compiler. > > But it already goes into protected mode ASAP. A 16-bit compiler is not > needed, though the code could be a little smaller if we had one. Ahh, but we do : /pub/FreeBSD/FreeBSD-current/ports/devel/bcc It's not that great, but it does work. > >> > There are four reasons : > >> > >> [Four good, irrelevant, and deleted reasons...] > > > > These reasons _AREN'T_ irrelevent, simply because they are the major > >reasons for having a PROTECTED mode in the first place. Which makes those > >reasons solely good and deleted. Yay. > > All four points are good, as I noted, but they just don't apply. > > Reason 1 is irrelevant because there's no VM in the bootloader. > Reason 2 is irrelevant because the bootloader doesn't take over the > hardware IRQ's from the BIOS. > Reason 3 is irrelevant because the bootloader doesn't make, or need to > make, multiple concurrent BIOS calls. > Reason 4 is irrelevant because the claim that the BIOS is untrustworthy > during boot time is ridiculous and not even worthy of debate, IMHO. I must have made that statement back when I thought that we were still talking about after-the-kernel-has-taken-control-of-the-system stage of boot, or later, such as while running the scheduler. > > THe VM86 facility you are talking about will ONLY exist after the kernel > >has 'taken over' the machine's state. > > So here you finally agree with me? Like I said, don't use vm86() mode until > the kernel takes over. Use real mode and protected mode, as appropriate, > until the kernel takes over. Why do you keep putting paren's around vm86? Are you referring to the VM86() functionality that Mike Smith is working on, or are you referring to a TSS with the vm86 adressing model? > [ ... much argument which arose from you and I thinking of different stages > of the boot provess deleted ... ] -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five."