Re: [PATCH][1/2] pvops-dom0: Xen acpi processor logic cleanup

[Jeremy Fitzhardinge <jeremy@goop.org>]

On 11/26/09 00:29, Yu, Ke wrote:
>>    * Split this into 3 patches:
>>          o revert the old Xen-specific changes
>>          o add the new common code (which may just be
>>            is_processor_apic_enabled())
>>          o add the new Xen-specific code in a new file
>>     
> Thanks for the comments. I split the original patch into three patch as you suggested. However, after it is done, I notice the original patch has already been checked in. so I just attach the three patch for your information, in case you still need that.
>   

Yes, that's why I'd like to see the revert patch separate.  Later on we
can fold together the patches to clean them up, but for now lots of
incremental delta patches is best.   And if we can avoid mixing Xen and
non-Xen changes into the one file, then its easier for subsystem
maintainers to see what we're doing to their code without getting stuck
in the details of the Xen-specific parts.

And can we split all the Xen-specific code into a new file?  I don't
want it mixed in with the generic ACPI code.

>>    * Make acpi_processor_driver a pointer to the preferred driver
>>      structure which defaults to the normal driver, and have some Xen
>>      code re-point it to the Xen one during Xen setup, rather than
>>      having an explicit Xen test in the core ACPI code
>>     
> This approach will introduce another dependency between xen setup code and acpi processor driver module, and again cannot pass compiling when CONFIG_ACPI_PROCESSOR=m. so I would suggest to keep it as it is. How do you think?
>   

Well, if ACPI_PROCESSOR=m then the corresponding Xen code would also
need to be modular.  But aside from that, it would work OK, wouldn't
it?  Rather than exposing the variable directly, it might be better to
wrap it with acpi_set_processor_driver() or something.  Or am I missing
something?

    J