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: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: [Xen-devel] RE: [PATCH][1/2] pvops-dom0: Xen acpi processor logic cleanup
From: "Yu, Ke" <ke.yu@xxxxxxxxx>
Date: Fri, 27 Nov 2009 10:23:45 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "Brown, Len" <len.brown@xxxxxxxxx>, "'xen-devel@xxxxxxxxxxxxxxxxxxx'" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 26 Nov 2009 18:24:46 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B0E3FF2.8060806@xxxxxxxx>
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> <4B0E3FF2.8060806@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcpudMO4LXFxqlufQQWUwq9vZFJJNgAjU7lQ
Thread-topic: [PATCH][1/2] pvops-dom0: Xen acpi processor logic cleanup
>-----Original Message-----
>From: Jeremy Fitzhardinge [mailto:jeremy@xxxxxxxx]
>Sent: Thursday, November 26, 2009 4:45 PM
>To: Yu, Ke
>Cc: 'xen-devel@xxxxxxxxxxxxxxxxxxx'; Brown, Len
>Subject: Re: [PATCH][1/2] pvops-dom0: Xen acpi processor logic cleanup
>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 
>checked in. so I just attach the three patch for your information, in case you 
>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.

Yes, this is more easy for maintenance. Will follow this way in later patches.

>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.

Yes. This is what I plan to do next step.

>>>    * 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
>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
>    J

I tried making xen code modular before, the issue here is the two-way 
dependency among acpi processor driver (driver/acpi/processor_core.c) and xen 
driver (driver/xen/acpi_processor.c). firstly, acpi processor driver depend on 
xen driver routine processor_cntl_xen_notify(). Secondly, if xen driver depend 
on some routine of acpi processor driver (e.g. acpi_set_processor_driver as you 
mentioned), then there is two way dependency between these two modules, which 
cannot pass compilation. so what I have done in last patch is moving related 
code from xen part to acpi processor driver part, to eliminate the xen->acpi 
processor dependency. 

Best Regards

Xen-devel mailing list