lkml.org 
[lkml]   [2012]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [PATCH 1/2] RFC: Prepare PAD for native and xen platform
On Sun, Feb 26, 2012 at 08:25:41AM +0000, Liu, Jinsong wrote:
> Liu, Jinsong wrote:
> > Jan Beulich wrote:
> >>>>> "Liu, Jinsong" <jinsong.liu@intel.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.

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?



\
 
 \ /
  Last update: 2012-02-26 18:41    [W:0.067 / U:3.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site