Date: Mon, 10 Nov 1997 02:58:48 -0800 From: Jonathan Mini <j_mini@efn.org> To: Tony Overfield <tony@dell.com> Cc: John-Mark Gurney <gurney_j@resnet.uoregon.edu>, Chuck Robey <chuckr@glue.umd.edu>, Mike Smith <mike@smith.net.au>, Terry Lambert <tlambert@primenet.com>, jamil@trojanhorse.ml.org, hackers@FreeBSD.ORG Subject: Re: >64MB Message-ID: <19971110025848.49607@micron.mini.net> In-Reply-To: <3.0.3.32.19971110035717.00704df0@bugs.us.dell.com>; from Tony Overfield on Mon, Nov 10, 1997 at 03:57:17AM -0600 References: <3.0.3.32.19971106150448.006d5438@bugs.us.dell.com> <Pine.BSF.3.96.971106073452.7018C-100000@picnic.mat.net> <199711061242.XAA00382@word.smith.net.au> <Pine.BSF.3.96.971106073452.7018C-100000@picnic.mat.net> <19971106094616.51849@hydrogen.nike.efn.org> <3.0.3.32.19971106150448.006d5438@bugs.us.dell.com> <19971106195834.34457@micron.mini.net> <3.0.3.32.19971110035717.00704df0@bugs.us.dell.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Tony Overfield <tony@dell.com> stands accused of saying: > First, it's entirely wrong for the application. The bootloader is a use32 > protected mode program. It makes transitions to real mode for BIOS calls > only. There's simply no need to address extended memory from real mode. > > Second, to me it seems a little bit silly to pop into protected mode then > back to real mode just so you can avoid protected mode. I realize that > there still exists some real-mode code that needs quick access to video > frame buffers and such, but that's another topic. The boot blocks need to be one _one_ state, and IMO there are only two states possible, and only one of those two is really a good idea. They are : 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) 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. The boot blocks shouldn't be constantly hopping from Real Mode to Protected Mode over and over again! This is insane, 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. > Third, it doesn't always work. Any time you give up the CPU to another > piece of code (ostensibly BIOS code), especially in real mode, there's a > chance that that code might take a brief trip into protected mode and when > it exits it might reload your descriptors with bonafide real-mode > compatible ones. Of course, you can fix them up when necessary, if you > know when they are clobbered. Of course, I'm not aware of any BIOS that > does this, but other BIOS "hookers" could be there, particularly in the > case of the DOS version of the bootloader. The BIOS does _NOT_ get to mess with the processor state once it hands control over to the boot code. The BIOS is no guaranteed to even have a ring 0 run state, and if it did this, 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 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) > 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. > >> My ambiguous question reworded would say... > >> > >> Once you are in the kernel startup code and running in protected mode, > >> why not simply switch back to real mode for BIOS calls and etc. instead > >> of trying to set up a VM86() facility? I think it's easier and much > >> better for compatibility while booting. > > > > 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. > Well, I'm fairly familiar with each of these bad things you've > mentioned, but it seems that I cannot keep the discussion centered > around the original topic. > > I have never suggested that real-mode be entered for BIOS calls after > the kernel has actually take over the VM, the IRQs, or the control of > devices. > > Specifically, I was talking about what happens or could happen during > the bootstrap process; the time before, during, and very slightly after > the kernel is loaded into memory. THe VM86 facility you are talking about will ONLY exist after the kernel has 'taken over' the machine's state. > In the context of bootloaders, it was suggested that because the > bootloader is completely out of space, that some (or even most) of the > things that one might like to locate in the bootloader should instead be > dragged into the kernel to be performed there. The assumption I made > (am I the only one who made this assumption?) is that the code moved to > the kernel is run almost immediately after the bootloader jumps to the > kernel. This is at least logically similar to it being an extension of > the bootloader. > > 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) 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? This I don't understand. -- 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."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971110025848.49607>