I'm thinking arch/i386/kernel/acpi.c should just go away, yes?
Its purpose is probably better served by an ifdef, like you mentioned.
Regards -- Andy
> -----Original Message-----
> From: Adam J. Richter [mailto:[email protected]]
> Sent: Tuesday, December 19, 2000 5:01 PM
> To: [email protected]; [email protected]
> Cc: [email protected]
> Subject: [Acpi] 2.4.0-test13pre3 acpi circular dependency
>
>
> Although the stock linux-2.4.0-test13pre3 does not allow
> one to build the acpi interpreter as a loadable module, I had
> tweaked the Makefiles in previous kernels to do this (the supporting
> code is there and it seemed to work, at least for shutting off the
> power after a shutdown). Unfortunately, in 2.4.0-test13pre3, this
> is no harder to do, because there is a circular dependency:
>
> drivers/acpi/ references acpi_get_rsdp_ptr in arch/i386/kernel/acpi.c,
> and
> arch/i386/kernel/acpi.c references acp_find_root_pointer in
> drivers/acpi/.
>
>
> I would like to recommend that the contents of
> arch/i{386,a64}/kernel/acpi.c be merged back somewhere in
> drivers/acpi/,
> and just selected with Makefile options, ifdefs, or perhaps runtime
> options (if the ia64 code is potentionally useable to an i386 kernel
> that find itself running on an ia64 CPU, which will probably
> be the case
> with most Linux distributions initially installed on ia64 hardware).
>
> If need be, I would be willing to at least write a quick and
> dirty #ifdef-based version of this proposed change.
The following fixes a circular depency problem between
drivers/acpi/ and arch/{i386,ia64}/kernel/acpi.c. I think the
problem only occurs if you manually tweak the build to make
acpi.o as a module, but it still should be fixed. This patch
also fixes the Makefiles in drivers/acpi so that they do not
blow up if you try to build drivers/acpi as a module (these
are corrections to some variable names, not a new functional
addition to the Makefiles).
I have deliberately not included the patch to change
CONFIG_ACPI into a tristate because I wonder if there is some problem
with acpi.o as a module that I am not aware of that is the reason
that CONFIG_ACPI in the stock kernels is configured as a boolean, even
though there is module initialization code in drivers/acpi, that seems
to work just fine, at least for my purposes of deactivating the
power after a shutdown. Does anybody know if there some known problem
with acpi.o as a module?
I have attached my kernel patch below. If this meets with
no obections, can somebody bless this and "send" it to Linus for
integration?
On Tue, Dec 19, 2000 at 06:00:15PM -0800, Grover, Andrew wrote:
> I'm thinking arch/i386/kernel/acpi.c should just go away, yes?
>
> Its purpose is probably better served by an ifdef, like you mentioned.
[...]
> > From: Adam J. Richter [mailto:[email protected]]
> >
> > Although the stock linux-2.4.0-test13pre3 does not allow
> > one to build the acpi interpreter as a loadable module, I had
> > tweaked the Makefiles in previous kernels to do this (the supporting
> > code is there and it seemed to work, at least for shutting off the
> > power after a shutdown). Unfortunately, in 2.4.0-test13pre3, this
> > is no harder to do, because there is a circular dependency:
> >
> > drivers/acpi/ references acpi_get_rsdp_ptr in arch/i386/kernel/acpi.c,
> > and
> > arch/i386/kernel/acpi.c references acp_find_root_pointer in
> > drivers/acpi/.
> >
> >
> > I would like to recommend that the contents of
> > arch/i{386,a64}/kernel/acpi.c be merged back somewhere in
> > drivers/acpi/,
> > and just selected with Makefile options, ifdefs, or perhaps runtime
> > options (if the ia64 code is potentionally useable to an i386 kernel
> > that find itself running on an ia64 CPU, which will probably
> > be the case
> > with most Linux distributions initially installed on ia64 hardware).
> >
> > If need be, I would be willing to at least write a quick and
> > dirty #ifdef-based version of this proposed change.
--
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
[email protected] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."