[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "Keir Fraser" <keir@xxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • 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
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.