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." _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel