Re: Removing acpi.ko support

2010-10-28 Thread Scott Long
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.

Scott


___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org


Re: Removing acpi.ko support

2010-10-28 Thread Nate Lawson
On 10/28/2010 9: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.

Fine with me. Users will still be able to disable ACPI if they want. And
systems that don't have ACPI (pre-2001) can still compile it out with
nodevice to save a few 100 KB of RAM. There's no reason to keep it as
a kernel module.

-- 
Nate

___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org


Re: Removing acpi.ko support

2010-10-28 Thread John Baldwin
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.

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.

-- 
John Baldwin
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org