On Tue, Dec 13, 2011 at 05:26:58PM +0800, liang tang wrote: > On 2011-12-13 15:45, Jan Beulich wrote: > >>>>On 12.12.11 at 18:29, Konrad Rzeszutek Wilk<konrad.wilk@xxxxxxxxxx> wrote: > >>On Thu, Dec 01, 2011 at 09:24:23AM +0000, Jan Beulich wrote: > >>>>>>On 30.11.11 at 18:21, Konrad Rzeszutek Wilk<konrad.wilk@xxxxxxxxxx> wrote: > >>>>--- a/drivers/acpi/Makefile > >>>>+++ b/drivers/acpi/Makefile > >>>>@@ -66,6 +66,7 @@ obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o > >>>> # processor has its own "processor." module_param namespace > >>>> processor-y := processor_driver.o processor_throttling.o > >>>> processor-y += processor_idle.o processor_thermal.o > >>>>+processor-y += processor_xen.o > >>>This should minimally be processor-$(CONFIG_XEN), with other things > >>>adjusted as necessary. > >>I was under the impression that this was required to get the > >>processor_xen.ko > >>to be a module. Otherwise it would only compile as built-in. > >processor_xen.ko? Why not have all the code go into processor.ko? > >(And the original construct didn't aim in that direction either.) > > > >Jan > > > the code about driver function which kernel > require(drivers/acpi/processor_xen.c ) build into processor.ko. > the code which have more relation with xen > (drivers/xen/acpi_processor.c) did not build into processor.ko. I am not sure if I understand you. Are you saying that the bulk of 'acpi_processor' (in the drivers/xen directory) should not be built in processor.o and that the config options will do that? But the config option is for the drivers/acpi directory.. So if I enable CONFIG_ACPI_PROCESSOR and CONFIG_ACPI_PROCESSOR_XEN then the build will stick processor_xen.o in to the processor.ko file. And if I select CONFIG_ACPI_PROCESSOR and unselect CONFIG_ACPI_PROCESSOR_XEN then I still get some of the processor_xen.o stuck in processor.ko file? (Granted, there is not much that gets stuck in b/c the majority of the code is guarded by a big #if defined(CONFIG_ACPI_PROCESSOR_XEN..) so the compiler might not stick anything in there) Is there a way to make it so there are _two_ modules: - processor.ko - processor-xen.ko [which uses some code from processor.ko] And they both can work together? Well, .. such that processor.ko does not really do anything since there are no cpuidle enabled, and the processor-xen.ko just deals with the parsing of ACPI Pxx states. And since cpuidle is disabled, there won't be any notify events sent anyhow so that could be removed (ah wait. the processor_xen.c does call processor_cntl_xen_notify(..PM_INIT) to pipe the data up.. so that is needed). In which case the processor-xen.ko only does one thing - parses the 'struct acpi_processor' data and pipes it up the hypervisor. Would this be feasible? > liang -- 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
