[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DE8DF0795D48FD4CA783C40EC82923350AD9BB@SHSMSX101.ccr.corp.intel.com>
Date: Thu, 23 Feb 2012 16:58:34 +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
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 :-)
>> depends on ACPI_PROCESSOR
>> depends on EXPERIMENTAL
>> depends on X86
>> + default n
>
> This is pointless.
Elaborate more? just a little curious why Kconfig has so many default n.
>
>> help
>> ACPI 4.0 defines processor Aggregator, which enables OS to
>> perform specific processor configuration and control that
>> applies to all
>
> Jan
--
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