Date: Tue, 18 Nov 1997 21:51:00 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: j_mini@efn.org Cc: tony@dell.com, hackers@freebsd.org Subject: Re: >64MB Message-ID: <199711182151.OAA23167@usr01.primenet.com> In-Reply-To: <19971118032353.57770@micron.mini.net> from "Jonathan Mini" at Nov 18, 97 03:23:53 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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. I can put my own feet in my mouth without help, thanks. 8-). 1) I want the boot blocks to run in real mode, and switch to protected mode before starting the kernel. The function of the boot blocks it to get the kernel loaded, not to do machine specific initialization. 2) I want the machine specific initialization to occur in the protected mode kernel, utilizing a VM86 TSS if it is necessary to do so (right now, it is, mostly because machine vendors don't care about protected mode code being able to call their BIOS). These goals aren't incompatible or mutually exclusive. > > > 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. "Correctly" in this case means not implementing a VM86() mechanism twice. Since FreeBSD itself needs this mechanism for BIOS based hardware initialization, as well as for possible future "fallback" drivers, the place to implement it is as part of a HAL. This is because VM86() is one of the services a HAL can provide on an x86 family processors. > > > 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. The boot blocks are the *only* place where this type of insanity is even mildly tolerable (IMO). The fact is, we need to know some things that the hardware specific BIOS knows, and which we can't know ourselves without calling the hardware specific BIOS, without becoming hardware specific too. Since it's unacceptable for us to be hardware specific, then we need to know where we can put code that is platform specific (ie: it assumes the existance of a BIOS and a mechanism to call it) without putting the burden in the boot blocks. The reason it can't go in the bootblocks is twofold: 1) The space available to the boot blocks is already too low to allow adding this kind of extension. 2) When porting to a new platform, I can hard-code the information I would get from the HAL interface for obtaining machine specific information. I can do this without having to make it work, initially. The boot code approach would require that I make everything work initially, and this means more work for a minimally functional "first pass" at a port... making ports less likely. They are already unlikely enough. 8-(. > > 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? That's my convention. The reason I use it is to distinguish a functional interface whereby protected mode code can call real mode code to get a result (like a BIOS function call effect) and have the results returned to the protected mode caller. A non-procedural VM86() implies the ability to run a real mode OS in a protected environment, but says nothing about the ability of the protected mode code to use the virtual machine for it's own ends (like making the BIOS call to ask the memory size). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711182151.OAA23167>