This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "Yu, Ke" <ke.yu@xxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH][1/2] pvops-dom0: Xen acpi processor logic cleanup
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Thu, 26 Nov 2009 00:44:34 -0800
Cc: "Brown, Len" <len.brown@xxxxxxxxx>, "'xen-devel@xxxxxxxxxxxxxxxxxxx'" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 26 Nov 2009 00:45:32 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4D05DB80B95B23498C72C700BD6C2E0B369D6BE1@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4D05DB80B95B23498C72C700BD6C2E0B369D687F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4B0D7C1A.9050309@xxxxxxxx> <4D05DB80B95B23498C72C700BD6C2E0B369D6BE1@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Lightning/1.0pre Thunderbird/3.0b4
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


Xen-devel mailing list