Date: Thu, 28 Oct 2010 13:44:16 -0600 From: Scott Long <scottl@samsco.org> To: John Baldwin <jhb@freebsd.org> Cc: "acpi@freebsd.org" <acpi@freebsd.org>, "arch@freebsd.org" <arch@freebsd.org> Subject: Re: Removing acpi.ko support Message-ID: <F48AFDDF-836D-498A-85DB-C780D9332A3A@samsco.org> In-Reply-To: <201010281529.03379.jhb@freebsd.org> References: <201010281254.39862.jhb@freebsd.org> <201010281402.48848.jhb@freebsd.org> <alpine.BSF.2.00.1010281248540.27323@pooker.samsco.org> <201010281529.03379.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 28, 2010, at 1:29 PM, John Baldwin <jhb@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F48AFDDF-836D-498A-85DB-C780D9332A3A>