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

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

I'm thinking about adding the following test-case to the "acpienabled?" word to 
add backward compatibility:

: acpienabled? ( -- flag )
        \ BEGIN: Additional code for backward compatibility
        s" loader_version" environment? if
                11 < if
                        \ older version of loader(8)
                        s" acpi_load" getenv
                        dup -1 = if
                                drop false exit
                        then
                        s" YES" compare-insensitive 0<> if
                                false exit
                        then
                then
        then
        \ END: Additional code for backward compatibility
        \ BEGIN: Existing code in HEAD
        s" hiint.acpi.0.disabled" getenv
        dup -1 <> if
                s" 0" compare 0<> if
                        false exit
                then
        else
                drop
        then
        true
        \ END: Existing code in HEAD
;

In-addition, I'm also thinking about adding the following test-case to the new 
"acpipresent?" word to add backward compatibility:

: acpipresent? ( -- flag )
        \ BEGIN: Additional code for backward compatibility
        s" loader_version" environment? if
                11 < if
                        \ older version of loader(8)
                        s" arch-i386" environment? if
                                drop true exit
                        else
                                false exit
                        then
                then
        then
        \ END: Additional code for backward compatibility
        \ BEGIN: Existing code in HEAD
        s" hint.acpi.0.rsdp" getenv
        dup -1 = if
                drop false exit
        then
        2drop
        true
        \ END: Existing code in HEAD
;

What do you think? I'm actually thinking this would be a good change to 
incorporate HEAD.
-- 
Cheers,
Devin Teske

-> CONTACT INFORMATION <-
Business Solutions Consultant II
FIS - fisglobal.com
510-735-5650 Mobile
510-621-2038 Office
510-621-2020 Office Fax
909-477-4578 Home/Fax
devin.te...@fisglobal.com

-> LEGAL DISCLAIMER <-
This message  contains confidential  and proprietary  information
of the sender,  and is intended only for the person(s) to whom it
is addressed. Any use, distribution, copying or disclosure by any
other person  is strictly prohibited.  If you have  received this
message in error,  please notify  the e-mail sender  immediately,
and delete the original message without making a copy.

-> END TRANSMISSION <-

_____________

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.
_____________
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Reply via email to