[UPDATE] New Boot-Loader Menu -- version 1.1

[John Baldwin]

On Tuesday, May 03, 2011 4:17:23 pm Devin Teske wrote:
> > -----Original Message-----
> > From: John Baldwin [mailto:jhb at freebsd.org]
> > Sent: Tuesday, May 03, 2011 12:20 PM
> > To: Devin Teske
> > Cc: freebsd-hackers at freebsd.org
> > Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1
> > 
> > On Tuesday, May 03, 2011 2:57:34 pm Devin Teske wrote:
> > > > From: John Baldwin [mailto:jhb at freebsd.org]
> > > > Sent: Tuesday, May 03, 2011 10:33 AM
> > > > To: Devin Teske
> > > > Cc: freebsd-hackers at freebsd.org; Olivier SMEDTS
> > > > Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.1
> > > >
> > > > On Tuesday, May 03, 2011 12:31:14 pm Devin Teske wrote:
> > > > >
> > > > > On May 3, 2011, at 4:45 AM, John Baldwin wrote:
> > > > >
> > > > > > On Monday, May 02, 2011 8:48:31 pm Devin Teske wrote:
> > > > > > > This version (1.1) works nearly identically to the standard
> > > > > > > menu that ships with FreeBSD in that it detects whether ACPI
> > > > > > > is enabled (truth be told, I actually re-used the "acpienabled?"
> > > > > > > function verbatim from /boot/beastie.4th by Scott Long and
> > > > > > > Aleksander Fafula). The ACPI detection of my boot loader
> > > > > > > (version
> > > > > > > 1.1 or higher) should be identical to the detection of the
> > > > > > > current boot-loader.
> > > > >
> > > > > Ugh. By "current", I meant 8.1-RELEASE (wasn't expecting this
> > > > > stuff to be different in HEAD, which it is).
> > > > >
> > > > >
> > > > > > Err, note that the acpienabled stuff is all different in HEAD
> > > > > > than in 7/8 since acpi.ko no longer exists.  You should use the
> > > > > > scheme from HEAD for handling ACPI present vs ACPI enabled/disabled.
> > > > > >
> > > > > > --
> > > > > > John Baldwin
> > > > >
> > > > >
> > > > > Ok, I see the new "acpipresent?" word (which replaces the "arch-i386"
> > > > > environment-test). Does this imply that we're going to support
> > > > > ACPI on
> > > > > non-i386 platforms (or already do)?
> > > >
> > > > amd64 and ia64 have always supported ACPI.  ia64 effectively requires it.
> > > > However, "hint.acpi.0.rsdp" is set by biosacpi.c in the i386 loader
> > > > bits, so other platforms will not set it, so the arch-i386 test is
> > > > no longer
> > > needed.
> > >
> > > If "hint.acpi.0.rsdp" is only set in the i386 pieces, wouldn't that
> > > imply that the "acpipresent?" would return FALSE on IA64?
> > 
> > Yes.  Right now the ACPI menu item is not displayed on ia64 and it never has
> > been.  You can't actually boot IA64 with ACPI disabled, so there's no reason
> for it
> > to be in the menu.
> 
> This raises a concern for my menu. Unlike the current menu, which blanks-out
> menuitem #2 for IA64, I've chosen instead to insert an inoperative menuitem with
> the text "ACPI Support: N/A".

Hmm, I think you should just leave the menu item blank or not listed.  It
doesn't make sense to see a knob about ACPI support on a ppc box for example,
and other platforms may grow platform-specific knobs in the future as well.

The current menu item is only blank as a hack to avoid renumbering the items.
If you are already changing that around, then I'd just leave it out altogether
unless ACPI is detected by the loader.

> So what do you think I should do?
> 
> a. Rewrite both "acpipresent?" and "acpienabled?" to be backward compatible with
> 6.x/older or
> b. embrace the future and simply warn about backward compatibility (or lack
> thereof) with respect to ACPI support.
> 
> NOTE: Route (a) may not be possible unless the loader_version was bumped at the
> same time that hint.acpi.0.rsdp was added.

(a) is not possible for the reason you mention.  I wouldn't worry about supporting
6.x at this point, esp. if it is going to be a pain.

-- 
John Baldwin