Konrad Rzeszutek Wilk wrote: > On Sun, Feb 26, 2012 at 08:25:41AM +0000, Liu, Jinsong wrote: >> Liu, Jinsong wrote: >>> 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 :-) >>> >> >> 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. > > What about the other approach I suggested where there are some > function overrides in osl.c? Something similar to > https://lkml.org/lkml/2012/1/17/401, specifically > https://lkml.org/lkml/2012/1/17/403 - that way you are not turning > the modules into being built in, but intead have the function table > already in the kernel (as some form of EXPORT_SYMBOL_GPL or a > registration function). > Thanks for the example (it's good itself :-), but per my understanding they are different cases. In the osl example case, tboot_late_init call acpi_os_set_prepare_sleep to register func, so it works no matter tboot.c built as y/n/m (through currently it's bool). However, in our case, we just cannot do so. We need 1. predefine a hook to native acpi pad funcs, take effect when static compile stage; 2. when xen init, redirect the hook to xen acpi pad funcs, take effect at running time; (The point is, we cannot do init twice for native and xen acpi pad, so we have to statically predefine a hook to native acpi_pad) For the reason above, I think we have to remove acpi_pad module, as long as we need to hook to native acpi_pad funcs. Thoughts? Regards, Jinsong -- 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
