From owner-freebsd-hackers Tue Nov 18 02:45:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA12374 for hackers-outgoing; Tue, 18 Nov 1997 02:45:32 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from bugs.us.dell.com (bugs.us.dell.com [143.166.169.147]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id CAA12328 for ; Tue, 18 Nov 1997 02:45:20 -0800 (PST) (envelope-from tony@dell.com) Received: from ant.us.dell.com (ant.us.dell.com [143.166.12.34]) by bugs.us.dell.com (8.6.12/8.6.12) with SMTP id EAA14263; Tue, 18 Nov 1997 04:44:12 -0600 Message-Id: <3.0.3.32.19971118043823.0071582c@bugs.us.dell.com> X-Sender: tony@bugs.us.dell.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Tue, 18 Nov 1997 04:38:23 -0600 To: Terry Lambert From: Tony Overfield Subject: Re: >64MB Cc: hackers@FreeBSD.ORG In-Reply-To: <199711102016.NAA13623@usr05.primenet.com> References: <3.0.3.32.19971110035805.006cab94@bugs.us.dell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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