Daniel Veillard wrote:
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
That sounds fine. Thanks for the offer, Daniel!
--
Elizabeth Kon (Beth)
IBM Linux Technology Center
Open Hypervisor Team
email: eak@xxxxxxxxxx
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list