Date: Tue, 18 Nov 1997 04:38:23 -0600 From: Tony Overfield <tony@dell.com> To: Terry Lambert <tlambert@primenet.com> Cc: hackers@FreeBSD.ORG Subject: Re: >64MB Message-ID: <3.0.3.32.19971118043823.0071582c@bugs.us.dell.com> In-Reply-To: <199711102016.NAA13623@usr05.primenet.com> References: <3.0.3.32.19971110035805.006cab94@bugs.us.dell.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 08:16 PM 11/10/97 +0000, Terry Lambert wrote: >> No, it's not impossible to do, it's just useless to do, IMHO, for the >> job at hand. I don't see any reason to turn the bootloader into a >> vm86() program that plays games like this just to copy to memory above >> 1 MB, since it's far easier to just switch modes and copy it directly. > >I think you are missing the point. There's no argument that the boot >loader should be a vm86() program. Ok, but it sure seemed like some people were arguing for this... >> 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 only argument is that it should >do the minimum possible work that can possibly be done before handing >the machine over to the kernel. I agree with this, but change "minimum possible" to "minimum necessary." >This is because the more the boot loader does, the more you will have >to rewrite for each new platform you port to, and the less it does, the >less you will have to rewrite. Well, where ever it's written, it will need rewriting. It's still system-dependant code, even if it lives in the kernel. I do understand that most folks would rather hack kernel code than bootloader code, however. >The point of accessing system information from the kernel where possible >is to make the boot-loader/kernel interconnect as architecturally >abstract as it can possibly be, so that the majority of the startup >code can be shared between architectures. The procedural abstraction, >if not the functional. Your kernel could obtain it from the bootinfo struct, if that's appropriate for the platform. It's still "obtained" by the kernel. >> >There are several other you can do using suspend/resume instructions and >> >similar tricks >> >> Suspend instruction? I could have sworn I knew them all by heart. > >There are "ICEBP" equivalents on non-Intel processors to do register >and processor state saves and restores; typically, they are used by >laptops for thjings like "suspend to disk" modes. Right, no such instruction for 94.736% (irresponsible, wild guess) of the CPU's in the world. Nice to know you're thinking about compatibility and portability. ;-) ;-) Actually, a laptop BIOS will simply poke itself into SMI mode to accomplish these things. It's much simpler that way, and it works on Intel's CPU's and many others. At least that's what I've always done. - Tony
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.3.32.19971118043823.0071582c>