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

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


  • To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Tue, 12 Jun 2007 08:42:32 +0100
  • Delivery-date: Tue, 12 Jun 2007 00:38:08 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AceW+39jOmNeDI8hQbKl0g0vvKGGDAVPuQRMABoe2rAACJdOpw==
  • Thread-topic: [Xen-devel] [PATCH 2/12] Pull necessary Linux PM files

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



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