From owner-freebsd-acpi@FreeBSD.ORG Thu Oct 28 19:44:49 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 C1EC2106566C; Thu, 28 Oct 2010 19:44:49 +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 785848FC14; Thu, 28 Oct 2010 19:44:49 +0000 (UTC) Received: from [10.70.143.238] (166-205-014-036.mobile.mymmode.com [166.205.14.36] (may be forged)) (authenticated bits=0) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id o9SJidYq036520; Thu, 28 Oct 2010 13:44:45 -0600 (MDT) (envelope-from scottl@samsco.org) References: <201010281254.39862.jhb@freebsd.org> <201010281402.48848.jhb@freebsd.org> <201010281529.03379.jhb@freebsd.org> In-Reply-To: <201010281529.03379.jhb@freebsd.org> Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8B117) From: Scott Long Date: Thu, 28 Oct 2010 13:44:16 -0600 To: John Baldwin X-Spam-Status: No, score=1.9 required=3.8 tests=MAY_BE_FORGED, MIME_QP_LONG_LINE, RCVD_IN_RP_RNBL, RDNS_DYNAMIC autolearn=no version=3.3.0 X-Spam-Level: * 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 19:44:49 -0000 On Oct 28, 2010, at 1:29 PM, John Baldwin 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 au= dience >>>>> of arch@ ] >>>>>=20 >>>>> I think we should drop support for having acpi load as a module for i3= 86. It >>>>> adds extra complication and hacks to the i386 APIC and interrupt code t= hat 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 wou= ld 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 r= emove >>>>> the various hacks on i386 and reduce differences with amd64. >>>>>=20 >>>>=20 >>>> 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=20 > 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? =20 > If it >>> goes away, don't forget to also update the bootforth code that knows how= to manipulate it. >>>=20 >>> It already does the right thing in this case (it did regardless, but tha= t was >>> part of the testing before enabling 'device acpi' in GENERIC for 8.0). I= f >>> we remove the KLD support then we can now remove that code from the load= er >>> and Forth scripts as they will no longer be needed. >>>=20 >>=20 >> You lost me, what is "the right thing". What I'm asking is whether there= =20 >> will be any surprises to people upgrading from 8.0 to 8.x with regard to=20= >> the bootloader no longer autoloading acpi.ko, and will there be any=20 >> surprises to those who update their bootblocks but maybe switch back and=20= >> forth between old and new kernels? >=20 > The loader code just sets 'acpi_load=3DYES'. 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. >=20 > 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 someo= ne > 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 aro= und > until 10.0 so there is one release branch worth of compatibility, though t= he > fact that GENERIC i386 in 8 ships with acpi compiled in and not a module o= n > i386 is probably already giving us a release branch of compatibility as it= is. >=20 I agree. > That is, a GENERIC 8.0 i386 kernel would work fine with a loader that remo= ved > the ACPI bits, only a 7.x GENERIC kernel would fail to autoload acpi.ko wi= th a > modified loader. Given that we don't generally support 7.x -> 9.0 upgrade= s, I > really think it would be ok to remove the loader support from 9. >=20 > However, what I really care about are the kernel changes, not the loader c= hanges. > The loader changes could wait until 10 if really necessary. >=20 >=20 Sounds like a good plan. I don't think that's there any reason to wait for 1= 0.0 Scott=