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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
>Sent: 2007年6月12日 15:43
>
>On 12/6/07 05:33, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>
>>> 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?
>
>Well, a judgment call is required. In the example you cite, entry.S cannot
>be merged because 32-bit and 64-bit assembly code is just plain
>different.
>But for head.S at least I was able to make *most* of the real-mode and
>32-bit protected mode common. I think that's a win, even though 100%
>merging
>in the boot/ directory was not possible.
>
>So the question is really how much merging is likely to be possible in the
>wakeup code (both C and asm, as I see the patch introduces both). My
>guess
>would be quite a lot, perhaps with ifdef for actual register load/save as
>the 64-bit register block is bigger. But you're best placed to say whether
>or not my guess is correct.
>
> -- Keir

I'm inclined to agree with your guess and wakeup part can be seen 
with more common stuff than boot code. Okay, without limitation to 
keep linux stuff strictly, I will start merging them into a Xen specific 
version.

Thanks,
Kevin

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