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). Instead of just one function being over-ridden it could have some more. However I am not sure if the osl.c is the place for this either. Perhaps Len might have some better ideas? -- 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
