[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350B2013@SHSMSX101.ccr.corp.intel.com>
Date: Sun, 26 Feb 2012 08:25:41 +0000
From: "Liu, Jinsong" <jinsong.liu@...el.com>
To: Jan Beulich <jbeulich@...e.com>,
"konrad.wilk@...cle.com" <konrad.wilk@...cle.com>
CC: "keir.xen@...il.com" <keir.xen@...il.com>,
"Brown, Len" <len.brown@...el.com>,
"Li, Shaohua" <shaohua.li@...el.com>,
"lenb@...nel.org" <lenb@...nel.org>,
"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 1/2] RFC: Prepare PAD for native and xen platform
Liu, Jinsong wrote:
> Jan Beulich wrote:
>>>>> "Liu, Jinsong" <jinsong.liu@...el.com> 02/23/12 2:29 PM >>>
>>> --- a/drivers/acpi/Kconfig
>>> +++ b/drivers/acpi/Kconfig
>>> @@ -213,10 +213,11 @@ config ACPI_HOTPLUG_CPU
>>> default y
>> >
>>> config ACPI_PROCESSOR_AGGREGATOR
>>> - tristate "Processor Aggregator"
>>> + bool "Processor Aggregator"
>>
>> There must be ways to address whatever strange problem you see
>> without making this piece of code non-modular.
>>
>
> Yes, another approach is x86_init approach, defining acpi_pad_ops at
> x86_init.c and overwritten when xen_start_kernel. This patch is just
> a RFC patch, to evaluate which approch is more reasonable :-)
>
Have a more think about it, x86_init approach still need to disable acpi_pad module.
Seems we have to set acpi_pad as bool, as long as it need to hook to native acpi_pad fucs/variables.
Thanks,
Jinsong--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists