[RFC] halt --no-apm

[RFC] halt --no-apm

[Robert Millan]

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?

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() ?

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

Re: [RFC] halt --no-apm

[Pavel Roskin]

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

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

-- 
Regards,
Pavel Roskin

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

Re: [RFC] halt --no-apm

[Pavel Roskin]

On Mon, 2008-09-08 at 20:29 +0200, Robert Millan wrote:

> 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?

Fine with me.  If somebody really needs "--no-apm" (which I doubt), it
could be reimplemented using a global variable.

-- 
Regards,
Pavel Roskin