Date: Tue, 18 Nov 1997 04:37:36 -0600 From: Tony Overfield <tony@dell.com> To: Jonathan Mini <j_mini@efn.org> Cc: hackers@freebsd.org Subject: Re: >64MB Message-ID: <3.0.3.32.19971118043736.006d7d48@bugs.us.dell.com>
next in thread | raw e-mail | index | archive | help
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. > 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. > 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). >and the processor (especially on a >P/Pro system) will be spending more time jumping in and out of Real Mode than >it will spend loading the kernel from disk. This is absurd on its face (at least it should be) and it's very easy to _prove_ as much. I'm not sure why you want to repeat this error. >it would break most DPMI or EMS servers, most >notably being Microsoft's EMM386 and Quarterdeck's QEMM. If the BIOS _did_ try >and mess with the machine state it wuold break Windows 95 and most people >running DOS. Somehow I doubt someone would break the spec in this way. 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. Fortunately, there's nothing to be gained by adding "big limits" code into a bootloader, so that whole discussion is tangential, unnecessary, and uninteresting. 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). ;-) >> I have seen instances where a timer or an asynchronous disk interrupt >> (yes, in DOS) has occurred that resulted in a "real-mode" task-switch >> and an interrupt-time reentry into INT 13h. If the INT 13h function >> were to reload the descriptors before returning, you would lose your >> big limits at an essentially unpredictable time. (NCACHE.EXE for you >> die-hard types.) > > Hello, we're not running DOS. We're talking about boot code from the >BIOS. Not TSR's or DOS device drivers here. (just us chickens) Umm, no need to condescend, I can follow all the details. I was stating generic, additional reasons to avoid the "big limits" real mode. I chose an actual, verifiable example in an effort to avoid speculation. I can speculate with high confidence, but to be sure, I often choose to use actual facts, even when they aren't identical to the topic at hand. >> 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. >> > 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. > 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. >> After the bootloader loads the kernel into memory, it jumps into it. >> The part that bothers me is that people want that instant in time to be >> a magical instant where you cannot call the BIOS in real mode anymore >> after having done so several thousands of times up to that point. Just >> because it's now running the "kernel" doesn't mean anything other than >> a jump (lret, in this case) has actually occurred. I was arguing that >> there is no reason for things to work differently (i.e. no real need >> for vm86()), until after the booting process has been completed and the >> kernel "proper" begins execution. > > Several 'magical' things HAVE happened to the machine at this point. One >of the most important is that the system has 'assumed' control of the ENTIRE >machine at this point in time. All IRQ's all memory mappings, and the status >of all devices. (read: probe pass will come soon, if it hasn't already >happened) No. Read my stuff again. You don't seem to see it. The kernel doesn't instantly take off probing devices, running tasks, and dispatching cron jobs the instant you first jump into it. There's a significant amount of code that runs, just as the bootloader does, before the magical point where the kernel actually takes over. > You are saying that after having spent all of the time up to this point >setting this situation up, that we should _give_ _up_ control and return it >to the BIOS temporarily? No, not at all. I'm just saying that we should spend a few more cycles "setting this situation up". Don't take over all control until it's appropriate and we don't urgently need anything else from the real-mode BIOS. In this $(subject) topic, the kernel would like to know how much extended memory is present so that it can use it. Why not call the extended memory map BIOS functions as the last several BIOS calls before taking over the system? After all, we just called it a few thousand times to get the kernel into memory. What's a few more going to hurt? Then, the kernel can take over, use all the memory, start probing and attaching devices, and ultimately create a vm86() for those fancy things that need it after the kernel is running. > This I don't understand. I hope it's more clear now. - Tony
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.3.32.19971118043736.006d7d48>