Re: [RFC] halt --no-apm

[Robert Millan]

On Mon, Sep 08, 2008 at 12:58:57PM -0400, Pavel Roskin wrote:
> On Mon, 2008-09-08 at 16:11 +0200, Robert Millan wrote:
> > Hi,
> > 
> > I'm confused as to what "halt --no-apm" could be useful for.  The code in
> > startup.S seems to check for APM before using it.  Is there any reason why
> > users would want an infin loop even when power-off is possible?
> 
> I guess the intention was to have a backup option if APM misbehaves,
> e.g. reboots the system or puts it to a busy loop with 100% CPU
> utilization.
> 
> By the way, I think we should use "cli" before entering the final loop,
> so that the interrupts don't wake up the CPU while it's waiting in
> "hlt".

Ok then.

> > Unfortunately it makes grub_halt() and all the code surrounding it less
> > portable, and for example it prevents unification of grub-emu declarations
> > in *.rmk.
> > 
> > If we really want to support "halt" as a command to bring GRUB to infin
> > loop, why not make this generic and support the same on all implementations
> > of grub_halt() ?
> 
> I think we want "halt" to turn off the system if possible, or put it to
> the lowest power state.  It's meant a fallback option when the OS cannot
> be booted.
> 
> If that means that "halt" should be system specific, so be it.  The
> fallback code could be shared on i386, but it's so short I doubt it's
> worth the trouble.

The problem is that this small difference makes the grub_halt() declaration
different, which propagates.  So what we have, for example, is that grub-emu
needs to be re-declared on each conf/i386-*.rmk file because it includes
util/i386/pc/misc.c which is i386-pc specific (actually this file is used on
non-i386-pc ports too, but that is a bug).

Though, for grub-emu the problem you describe is not significant, since the
BIOS isn't there to missbehave.  Perhaps we could make i386-pc's grub-emu
use "grub_halt (void)" instead?

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