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

RE: [Xen-devel] [Patch 1/2] Re-org dom0_ops.h to allow arch specificdefinition


  • To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
  • Date: Fri, 17 Jun 2005 09:25:18 +0100
  • Delivery-date: Fri, 17 Jun 2005 08:24:22 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcVyXEnsibufuu7JRVC9zWVOoEIwJwAuN9GQ
  • Thread-topic: [Xen-devel] [Patch 1/2] Re-org dom0_ops.h to allow arch specificdefinition

> I'm not sure whether this is right way to go, but sometimes 
> specific architecture may have its own different dom0 
> operations. Attached patch tries to arrange definition of 
> operations to the way where each architecture is allocated 
> with exclusive 64 operation IDs. And common operations occupy 
> first segment.

It probably makes sense not to re-use arch-specific dom0_op numbers
(though there wouldn't be any real abiguity), but I'm not sure its worth
trying to carve up the number space like this.

I guess there's an argument for renaming the arch-specific dom0 ops to
put X86 or IA64 in the name, but I don't think there's any real
confusion. Perhaps we should split out arch definitions from dom0_ops.h?


I'm inclined not to do much in the way of rearranging until post 3.0.
After 3.0 I'd like to rename dom0_ops altogether, and implement finer
grained delegation of control operations. 

Comments?

Ian 

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