Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 3 May 2011 13:17:23 -0700
From:      "Devin Teske" <dteske@vicor.com>
To:        <freebsd-hackers@freebsd.org>
Subject:   RE: [UPDATE] New Boot-Loader Menu -- version 1.1
Message-ID:  <004901cc09cf$1da33fe0$58e9bfa0$@vicor.com>
In-Reply-To: <201105031519.40087.jhb@freebsd.org>
References:  <9B387DE4-6866-4208-A8FC-6516D651F6A5@vicor.com> <201105031332.41827.jhb@freebsd.org> <004501cc09c3$f740e600$e5c2b200$@vicor.com> <201105031519.40087.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message-----
> From: John Baldwin [mailto:jhb@freebsd.org]
> Sent: Tuesday, May 03, 2011 12:20 PM
> To: Devin Teske
> Cc: freebsd-hackers@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@freebsd.org]
> > > Sent: Tuesday, May 03, 2011 10:33 AM
> > > To: Devin Teske
> > > Cc: freebsd-hackers@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".

What do you think would be an appropriate stand-in? Perhaps "ACPI Support:
Enabled" (simply assume that it's enabled and do nothing if the user attempts to
disable it) or "ACPI Support:" with no text (or maybe what I've got right now --
"ACPI Support: N/A" -- is already acceptable)?

> 
> > > > I also see the rewritten "acpienabled?" word. Nice. I'll slurp it
> > > > in to make my ACPI detection the same as HEAD.
> > > >
> > > > I also performed some backward compatibility tests. Looks like
> > > > this will be backward compatible with 8.1-RELEASE (loader_version ==
11).
> > > > However, the code in HEAD appears to not work in 8.0-RELEASE
> > > > (loader_version == 8).
> > >
> > > Hmm, which part does not work in 8.0?  arch-i386 has existed since
> > > at least 4.x I thought, and the ACPI bits have been setting
> > > hint.acpi.0.rsdp since 7.0 (sys/boot/i386/libi386/biosacpi.c CVS rev
> > > 1.12
> > added it).
> > >
> > > --
> > > John Baldwin
> >
> > I've got this 8.0-STABLE box. I don't know exactly when it was
> > installed, but /boot/loader has a timestamp from June 2010 and when I
> execute:
> >
> > 	s" loader_version" environment? drop .
> >
> > I get "8", whereas when I boot the same exact hardware with
> > 8.1-RELEASE, I get "11".
> >
> > When I boot 8.0-STABLE (loader_version 8), I do not have "hint.acpi.0.rsdp"
> > whereas if I boot 8.1-RELEASE (loader_version 11), I do get
"hint.acpi.0.rsdp".
> > (NOTE: this is on the exact same hardware, without changing any BIOS
> > settings between boots).
> >
> > Is it possible that my 8.0-STABLE has a loader that is older than
7.0-RELEASE?
> > I'm
> > trying to figure out why this 8.0-STABLE box is not setting
hint.acpi.0.rsdp.
> 
> What is the output of 'kenv | grep acpi' from your old loader?
> 
> Hmm, sys/boot/i386/loader/version was bumped to 1.1 in 5.0 release.  It was
> bumped to 1.0 in 5.0-CURRENT.  It was last 0.8 (so "8") in 4.x.

D'OH!

Someone had slapped a 4.9.1 hard disk into this 8.0-STABLE box without me
knowing. Turns out I was booting from the 4.9.1 disk and hence why the old
loader.

Thanks for helping me figure that one out.

Back to the topic of backward compatibility.

As it stands, it would seem that the new "acpipresent?" will not produce
expected results on releases older than 7.0 (since hint.acpi.0.rsdp is not set
in 6.x or older). The result would be that if used on FreeBSD 6.x or older, that
the boot menu would always blank-out the ACPI option. This is not an issue for
the FreeBSD release engineers, but for my package -- which might potentially be
added to a FreeBSD-6 box -- in which case ACPI will not detect properly.

So, I'm in a quandary over the new "acpipresent?". If I take it as-is, I'll have
to warn downloaders that ACPI won't be detected properly on 6.x or older.
However, if I modify it, then my code cannot be committed to CVS without
modification (that is to say, that if/when this makes it to the base, that
backward compatibility might need to be removed).

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.

Thoughts?
--
Devin

_____________

The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
_____________



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?004901cc09cf$1da33fe0$58e9bfa0$>