On Tue, Sep 11, 2007 at 03:08:46AM +0100, Daniel P. Berrange wrote: > On Mon, Sep 10, 2007 at 09:52:46PM -0400, beth kon wrote: > > Daniel, > > > > I'm taking a stab at this work and want to be sure I'm taking the right > > approach. I'm new to xen and even newer to libvirt, so have a bit of a > > learning curve. I suggest the following: I make all the libvirt specific infrastructure work to plug the new calls which is where I will be the most efficient, and I let you plug code to talk to Xen which is where you will be more up to date and able to test, okay ? > > For the topology information, I assume that this will be a call through > > xend, similar to xenDaemonNodeGetInfo. It would seem natural to somehow > > extend the xenDaemonNodeGetInfo with this additional information except > > that you suggested having the output in XML. Can you explain why you > > chose XML? > > We have to maintain 100% ABI & API compatability against older releases > of libvirt. This means that once we add a function, struct or other > definition in the header files it cannot ever be changed again. So this > means we can't change the virNodeInfo struct to add NUMA info. > > For this reason we tend to keep struct's just for use in APIs where the > performance is critical, or data set is unlikely to ever change. So far > we only use structs for virDomainInfo, virNodeInfo, virSchedParam and > virVcpuInfo at this time. For more descriptive data we format information > into an XML document. This makes it very easy to add new XML elements and > attributes to represent new data items. The same compatability rules apply > to XML though - once we add an attribute or element it can never be removed > from the spec. Currently we think putting the NUMA info into XML is the > best approach since it is not performance critical. > > > There are two ways to implement it with Xen - either talk to XenD and > extract the topology there, or make direct hypercalls. For now it is > probably easiest to talk to XenD, since this isn't performance critical. Agreed, we could use the hypervisor calls but that means extending that module which is already a bit painful for all the backward compatibility workaround. Xend access should be simpler, at least in a first implementation. I will try to come later today with a first patch defining the framework and leaving functions to fill for the new calls in the xend_internal.c backend. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list