Re: [PATCH] Enable grub_cpu_idle for i386 to halt the CPU

[Robert Millan <rmh@aybabtu.com>]

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.
> 
> <sarcasm>
> </sarcasm>

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."