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

RE: [Xen-ia64-devel] RE: Code merge between VTI code and non VTI code


  • To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, "Yang, Fred" <fred.yang@xxxxxxxxx>
  • From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
  • Date: Thu, 19 May 2005 09:58:54 +0800
  • Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 19 May 2005 01:59:51 +0000
  • List-id: DIscussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AcVWQvKg47P+8ri/Rz2eCbb86mLeRQAIRo+AAExKdUAADj3+0AAB8clAAHgKNVAAHdw84ABQqqDAABTosnAAAqCPgAAEqoDAAAzRV3A=
  • Thread-topic: [Xen-ia64-devel] RE: Code merge between VTI code and non VTI code

> What I am saying is there may be (in fact very likely *will* be)
> some parts of the code where architecture and design objectives
> should result in divergence.  I don't think we have explored
> these areas well enough yet and merging too quickly limits our
> options and flexibility.
> 
Dan:
        Yes, there maybe divergence, but what I am suggesting is not
touching the divergence now. Merging VCPU context definition (step1),
pt_regs (step2), domain N support (step 3) will never get rid of those
divergence you may see. The only reason to do so is that we don't want
to see every bug fixes/new features be done in 2 seperate place and 2
routines. What I am suggesting is to let one structure work for both. If
we can dig into details, that will help us to remove your concern. How
about to move to the thread for vcpu context merge? Any comments for
that?
Eddie

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


 


Rackspace

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