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

RE: [Xen-merge] xen-merge mailing list

To: "Chris Wright" <chrisw@xxxxxxxx>, "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Subject: RE: [Xen-merge] xen-merge mailing list
From: "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
Date: Thu, 28 Jul 2005 22:44:38 -0700
Cc: xen-merge@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 29 Jul 2005 05:43:03 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-merge-request@lists.xensource.com?subject=help>
List-id: xen-merge <xen-merge.lists.xensource.com>
List-post: <mailto:xen-merge@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-merge>, <mailto:xen-merge-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-merge>, <mailto:xen-merge-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-merge-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcWT+enWLP7exrnHSXCfOHUFtBjkRQAA12sQ
Thread-topic: [Xen-merge] xen-merge mailing list
Chris Wright wrote:
> * Ian Pratt (m+Ian.Pratt@xxxxxxxxxxxx) wrote:
>> Please excuse me from auto-subscribing you to this list, but I
>> figured it would be useful to have a list dedicated for discussion
>> about getting arch-xen prepared for sending upstream.
> 
> Thanks for setting that up Ian.
> 
>> It's pretty clear that we need to move fast on this, lest we get
>> stuck with the VMware VMI proposal that just doesn't do what we need
>> to get good performance.  I'd much rather get our patch in first and
>> add their hooks to our stuff, rather than being forced to work
>> within the framework of their very low-level approach.
> 
> I agree, it makes sense to get things in, and let later work go on
> with something concrete in place.
> 
>> So, how best to go about this? Can we parallelize the work? Where to
>> start?
> 
> I've started by simply creating an i386 sub-arch and moving bits over.
> (nowhere near compiling, just trying to get a handle on how much work
> there is and how it will split out).  I use this dumb script that
> basically diffs arch/xen/i386/* against arch/i386/*, for example,
> to generate the actual changes.  This could literally go file by file
> with an eye for basic cleanups.  We've had a few suggestions about the
> cleanups, such as ifdefs based on some config which essentially says
> physical machine, to effectively comment code out for Xen, or actual
> inlines and macros that are populated by the sub-arch.  Likely both
> are options depending on the specifics.  For example, x86_64 has
> method for alternative apic, I wonder if such a scheme might not be
> useful for i386 as well?

I'm not sure if there is a VMI patch against x86_64 at this point, but
I'm cleaning up the x86_64 code so that we can share the code with the
native Linux cleanly. At this point, I'm using #ifdef CONFIG_XEN as
agreed with Andi.

> 
> Also, Andi mentioned to me that he'd actually prefer to try and merge
> the x86_64 bits directly into the x86_64 port rather than add a
> sub-arch there if possible (Andi, please correct me if I
> misunderstood). 

In that case how do we switch the kernels headers for xenlinux? 

> 
>> Anyone interested in a trip to Cambridge to work on this stuff? It's
>> a nice time of year for a visit -- nice warm summer evenings sitting
>> in beer gardens...
> 
> Hmm, quite tempting.
> 
> thanks,
> -chris
> 

Jun
---
Intel Open Source Technology Center

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

<Prev in Thread] Current Thread [Next in Thread>