Removing acpi.ko support

Scott Long scottl at samsco.org
Thu Oct 28 19:44:49 UTC 2010


On Oct 28, 2010, at 1:29 PM, John Baldwin <jhb at freebsd.org> wrote:

> On Thursday, October 28, 2010 2:50:42 pm Scott Long wrote:
>> On Thu, 28 Oct 2010, John Baldwin wrote:
>>> On Thursday, October 28, 2010 1:01:24 pm Scott Long wrote:
>>>> On Oct 28, 2010, at 10:54 AM, John Baldwin wrote:
>>>>> [ cc'ing acpi@ to be safe, but I think the topic warrants the wider audience
>>>>> of arch@ ]
>>>>> 
>>>>> I think we should drop support for having acpi load as a module for i386.  It
>>>>> adds extra complication and hacks to the i386 APIC and interrupt code that are
>>>>> gratuitously different from amd64 as a result.  Originally it was made a
>>>>> module so that GENERIC on i386 did not include ACPI by default but would only
>>>>> use up memory to hold ACPI-related code if the machine supported ACPI.  Now
>>>>> that acpi is part of GENERIC on i386 in 8.0 and later this argument is no
>>>>> longer relevant.  I'd like to remove support for ACPI as a module to remove
>>>>> the various hacks on i386 and reduce differences with amd64.
>>>>> 
>>>> 
>>>> Just to be clear, it'll still be an optional kernel device, it just won't be a KLD anymore, right?  If you do that, what will happen with the 
> evil
>>> bootloader code that gropes around for the AML tables and auto-loads the module?  Is there any reason to keep that around for compatibility?  
> If it
>>> goes away, don't forget to also update the bootforth code that knows how to manipulate it.
>>> 
>>> It already does the right thing in this case (it did regardless, but that was
>>> part of the testing before enabling 'device acpi' in GENERIC for 8.0).  If
>>> we remove the KLD support then we can now remove that code from the loader
>>> and Forth scripts as they will no longer be needed.
>>> 
>> 
>> You lost me, what is "the right thing".  What I'm asking is whether there 
>> will be any surprises to people upgrading from 8.0 to 8.x with regard to 
>> the bootloader no longer autoloading acpi.ko, and will there be any 
>> surprises to those who update their bootblocks but maybe switch back and 
>> forth between old and new kernels?
> 
> The loader code just sets 'acpi_load=YES'.  If acpi is compiled into the
> kernel or it is not present it just silently fails.  This was already
> considered and tested during the 8.0 release cycle.
> 
> I am only proposing making this change for 9, FYI, not to MFC it.  If we
> were to remove the code from the loader that sets acpi_load in 9 and someone
> booted an 8.x or 7.x kernel that did not include 'device acpi', then acpi.ko
> would not be autoloaded.  We could easily leave the code in the loader around
> until 10.0 so there is one release branch worth of compatibility, though the
> fact that GENERIC i386 in 8 ships with acpi compiled in and not a module on
> i386 is probably already giving us a release branch of compatibility as it is.
> 

I agree.

> That is, a GENERIC 8.0 i386 kernel would work fine with a loader that removed
> the ACPI bits, only a 7.x GENERIC kernel would fail to autoload acpi.ko with a
> modified loader.  Given that we don't generally support 7.x -> 9.0 upgrades, I
> really think it would be ok to remove the loader support from 9.
> 
> However, what I really care about are the kernel changes, not the loader changes.
> The loader changes could wait until 10 if really necessary.
> 
> 

Sounds like a good plan.  I don't think that's there any reason to wait for 10.0

Scott


More information about the freebsd-acpi mailing list