svn commit: r204877 - head/sys/modules/acpi/acpi

[John Baldwin]

On Monday 08 March 2010 8:35:42 pm Jung-uk Kim wrote:
> On Monday 08 March 2010 05:52 pm, Jung-uk Kim wrote:
> > On Monday 08 March 2010 05:25 pm, John Baldwin wrote:
> > > On Monday 08 March 2010 5:11:42 pm Jung-uk Kim wrote:
> > > > On Monday 08 March 2010 04:11 pm, John Baldwin wrote:
> > > > > On Monday 08 March 2010 2:40:31 pm Jung-uk Kim wrote:
> > > > > > Author: jkim
> > > > > > Date: Mon Mar  8 19:40:31 2010
> > > > > > New Revision: 204877
> > > > > > URL: http://svn.freebsd.org/changeset/base/204877
> > > > > >
> > > > > > Log:
> > > > > >   Enable ACPI module build on amd64.  Although we strongly
> > > > > > recommend building it into kernel, there is no need to
> > > > > > prevent it from building at all.
> > > > >
> > > > > (Oops, ignore previous spurious reply).
> > > > >
> > > > > Please revert this.  The MADT parser on amd64 is slightly
> > > > > different from i386 and will not work when acpi is loaded as
> > > > > a module.  If anything, I would prefer we make acpi not be a
> > > > > module on i386. There are several things that would be far
> > > > > less invasive to implement via #ifdef DEV_ACPI than by
> > > > > defining runtime kobj interfaces to the ACPI driver.
> > > >
> > > > madt.c itself is not very different but I understand what you
> > > > are trying to explain here.  In fact, I tested it before
> > > > committing and the trick was adding mptable in place of acpi. 
> > > > It worked fine although it may not be ideal.  I can back out
> > > > sys/modules/acpi/Makefile change if you agree, however.
> > >
> > > It is different enough.  Specifically, the amd64 one sets a
> > > "better" value for mp_maxid than i386, but it can only do this
> > > because it can run before SI_SUB_KLD since it is never invoked as
> > > a module.  I still think that we should probably be moving away
> > > from acpi.ko rather than towards for other reasons.
> >
> > I noticed that and I used mptable instead, which seems to do well
> > enough for the job.  Please keep in mind that I am not trying to
> > promote acpi.ko at all.  I just want to make sure acpi.ko can be
> > built and loaded without builing and installing the whole
> > world/kernel for i386 to test new ACPICA. :-(
> >
> > Any way, I will just revert sys/modules/acpi/Makefile change, then.
> > It should be a reasonable compromise, deal?
> 
> I thought you complained because I accidentally committed my local 
> changes to sys/modules/acpi/Makefile.  In fact, I didn't. :-) Do you 
> still think I should back it out?  Or is it okay?

I think it should be backed out.  The MP table is not really a good workaround 
as you cannot mix and match ACPI and MP table for PCI interrupt routing.  Or 
rather, if you use the MP Table, we have to use it for all PCI stuff and 
cannot use ACPI for any PCI-related stuff, so it's not really ideal.  I don't 
think the system quite does the right thing though.  I suspect it is still 
using ACPI to manage PCI and you are just getting lucky that ACPI numbers the 
IO APIC IRQs the same way FreeBSD's MP Table driver happens to do.

Also, the MP Table is not always kept up to date in modern BIOSes.  Since most 
modern OS's only use the ACPI tables, BIOS writers do not test the MP Table, 
and I know of one instance a few years ago where Intel shipped a completely 
wrong MP Table for a new platform because nothing they tested used it.

If all you want is the ability to build an acpi.ko but not to actually use it, 
then maybe you could only enable building the module if a special variable is 
set?  That is, you could do 'make BUILD_KLD=yes' in sys/modules/acpi/acpi to 
build the module for debugging.  However, a default build (such as building 
GENERIC) would not build or install acpi.ko.  I just build a full kernel to 
test ACPI changes myself.

-- 
John Baldwin