From owner-freebsd-acpi@FreeBSD.ORG Thu Oct 28 18:50:48 2010 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 622541065698; Thu, 28 Oct 2010 18:50:48 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 058B78FC18; Thu, 28 Oct 2010 18:50:47 +0000 (UTC) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id o9SIogog036148; Thu, 28 Oct 2010 12:50:42 -0600 (MDT) (envelope-from scottl@samsco.org) Date: Thu, 28 Oct 2010 12:50:42 -0600 (MDT) From: Scott Long To: John Baldwin In-Reply-To: <201010281402.48848.jhb@freebsd.org> Message-ID: References: <201010281254.39862.jhb@freebsd.org> <8019DAB7-8276-451D-812D-2C5EAB8F6CB9@samsco.org> <201010281402.48848.jhb@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: acpi@freebsd.org, arch@freebsd.org Subject: Re: Removing acpi.ko support X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 18:50:48 -0000 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? Scott