Jan Beulich wrote: >>>> "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> 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-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
