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

Jung-uk Kim jkim at FreeBSD.org
Tue Mar 9 18:03:58 UTC 2010


On Tuesday 09 March 2010 07:53 am, John Baldwin wrote:
> 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.

Understood.  Thanks for the detailed explanation.

> 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.

I am well aware of this issue.

> 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.

And we do not build or install acpi.ko by default as you expected:

# $FreeBSD: head/sys/modules/acpi/Makefile 194701 2009-06-23 13:17:25Z rpaulo $

.if ${MACHINE} == "i386"
SUBDIR=		acpi
.endif

SUBDIR+=	acpi_aiboost acpi_asus acpi_fujitsu acpi_hp acpi_ibm    \
		acpi_panasonic acpi_sony acpi_toshiba acpi_video        \
		acpi_dock acpi_wmi 

.include <bsd.subdir.mk>

You have to descend to the subdir and build/install manually and
that's all I wanted.

> I just build a full kernel to test ACPI changes myself.

Thanks.

Jung-uk Kim


More information about the svn-src-head mailing list