WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] [PATCH 2/12] Pull necessary Linux PM files

To: "Keir Fraser" <keir@xxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH 2/12] Pull necessary Linux PM files
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Tue, 12 Jun 2007 12:33:03 +0800
Delivery-date: Mon, 11 Jun 2007 21:31:22 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C2932406.10782%keir@xxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AceW+39jOmNeDI8hQbKl0g0vvKGGDAVPuQRMABoe2rA=
Thread-topic: [Xen-devel] [PATCH 2/12] Pull necessary Linux PM files
>From: Keir Fraser [mailto:keir@xxxxxxxxxxxxx]
>Sent: 2007年6月11日 23:09
>
>Could we not share some of this low-level code across 32 and 64 bits? A
>good
>deal of it must be real mode asm anyway. Also it's weird that only x86/64
>gets a new header file.

Well, the reason is that we planned to use copy-and-modify style when 
borrowing logic from Linux in the start, like using "#ifdef __XEN__" for 
xen specific changes. Since too many modifications with ifdef makes 
patch difficult to read, we are conservative to change code/file logic 
from Linux side. 

If that comparison to Linux is not necessary, I agree that to cleanup 
with common logic can make patch much simpler. Actually there are 
even some dead code from Linux side.

>
>Overall, I think we should pick the cleanest one (x86/32 or x86/64) as a
>starting point and then bludgeon the code so that it works for the other
>sub-architecture too. This might involve a new file in the subarch
>directories, but only for code that actually really is specific to that
>subarch.
>

But before going this way, I have a question about to which extent we 
should consider common code instead of subarch duplication. Xen 
relocate patch merged boot assembly code between 32 and 64, 
though common lines in head.S are even less than arch differences. 
Will that make code less readable instead? Do you plan to merge 
more like entry.S? 

>Or are there more fundamental differences than it first appears?
>

Should be no, since it's largely like a boot code to recover processor context.


>Also, I applied two of your patches now, which you will find in the staging
>tree (one in xen, one in linux). It would be useful if you would resync the
>remainder.
>
> -- Keir

Thanks. I'll first resync rest patches to make sure it working still, and 
then go back to cleanup the wakeup part as you suggested. This time 
I'll discard #ifdef __XEN__ style since the final code may warp more 
from linux side which would make copy-and-change patch completely 
messed. 

Thanks,
Kevin
>
>On 15/5/07 15:15, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>
>> Just borrow 5 files from Linux, for necessary cpu context
>> save/restore and wakeup stub. Except them, all the ACPI
>> related operations are still carried by dom0.
>>
>> Signed-off-by Ke Yu <ke.yu@xxxxxxxxx>
>> Signed-off-by Kevin Tian <kevin.tian@xxxxxxxxx>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel