From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KUjpW-00041y-8k for mharc-grub-devel@gnu.org; Sun, 17 Aug 2008 11:06:06 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KUjpU-0003yf-BY for grub-devel@gnu.org; Sun, 17 Aug 2008 11:06:04 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KUjpT-0003xx-Or for grub-devel@gnu.org; Sun, 17 Aug 2008 11:06:03 -0400 Received: from [199.232.76.173] (port=43799 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KUjpT-0003xi-Ln for grub-devel@gnu.org; Sun, 17 Aug 2008 11:06:03 -0400 Received: from aybabtu.com ([69.60.117.155]:48203) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KUjpT-0001wy-5X for grub-devel@gnu.org; Sun, 17 Aug 2008 11:06:03 -0400 Received: from [192.168.10.10] (helo=thorin) by aybabtu.com with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1KUjgw-0007Ms-Dq for grub-devel@gnu.org; Sun, 17 Aug 2008 16:57:15 +0200 Received: from rmh by thorin with local (Exim 4.63) (envelope-from ) id 1KUjo9-0002V4-6y for grub-devel@gnu.org; Sun, 17 Aug 2008 17:04:41 +0200 Date: Sun, 17 Aug 2008 17:04:41 +0200 From: Robert Millan To: The development of GRUB 2 Message-ID: <20080817150441.GB9153@thorin> References: <20080812030708.GB16592@spacedout.fries.net> <20080812091037.GC381@thorin> <20080816031109.GD16592@spacedout.fries.net> <20080816123317.GE6334@thorin> <20080816144422.GE16592@spacedout.fries.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080816144422.GE16592@spacedout.fries.net> Organization: free as in freedom X-Message-Flag: Worried about Outlook viruses? Switch to Thunderbird! www.mozilla.com/thunderbird X-Debbugs-No-Ack: true User-Agent: Mutt/1.5.13 (2006-08-11) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: [PATCH] Enable grub_cpu_idle for i386 to halt the CPU X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2008 15:06:04 -0000 On Sat, Aug 16, 2008 at 09:44:22AM -0500, David Fries wrote: > On Sat, Aug 16, 2008 at 02:33:17PM +0200, Robert Millan wrote: > > > > We have 4 ports on i386. A proper implementation of grub_cpu_idle > > should work fine on all of them. When I say "proper" I mean that > > 'hlt' instruction should be usable without doing strange gimmicks. > > > Please try to use proper tone if you want us to have a reasonable discussion. > > Your patch simply works around the fact that 'hlt' is broken on 32-bit by > > going back to i8086 mode in order to use it. > > Pavel Roskin didn't like an earlier patch of mine to add a whole 10 > assembly instructions to the core.mod. This is the first time I've > dealt with the uglieness of BIOS, Your patch doesn't deal with the BIOS in any way. It simply takes advantage that interrupts are setup in i8086 mode to use hlt there. It is a trivial workaround, and I'd have done that myself when implementing grub_cpu_idle if it wasn't because it's an ugly hack. > for reimplementing an interrupt stack and drivers > to acknowledge those interrupts, Interrupt stack and drivers? The only thing you need for hlt to work is install a dummy stub in idt[0], disable all other IRQs and set the interrupt flag. > when grub heavily depends on BIOS to > be there and working. GRUB is a multiplatform bootloader. When writing multiplatform code, it is IMHO very important to make the code as generic as reasonably possible. Use of 'hlt' instruction depends on a particular setup of the CPU, and has nothing to do with firmware facilities. > Maybe I should mention that hlt is already being used in real mode. > Protected mode interrupts would cause that to break. Can you ellaborate on that? -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all."