Re: [Libvir] [PATCH 1/2] Add internal API for managing capabilities data
Yes, this all looks good. Another advantage of doing this is that we can be sure that the capabilities XML generated by each driver will have the same schema. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [PATCH 1/2] Add internal API for managing capabilities data
On Tue, Feb 26, 2008 at 09:39:49AM +, Richard W.M. Jones wrote: Yes, this all looks good. Another advantage of doing this is that we can be sure that the capabilities XML generated by each driver will have the same schema. Yes indeed - this is a very good benefit, particularly as we extend the capabilities with more data like NUMA / migration / etc. At some point I think it'd be interesting to do a similar refactoring for domains. So we could have an internal virDomainDefPtr to store the definitions and a generic XML formatter / XML parser shared by all drivers. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [PATCH 1/2] Add internal API for managing capabilities data
On Tue, Feb 26, 2008 at 12:52:32PM +, Daniel P. Berrange wrote: On Tue, Feb 26, 2008 at 09:39:49AM +, Richard W.M. Jones wrote: Yes, this all looks good. Another advantage of doing this is that we can be sure that the capabilities XML generated by each driver will have the same schema. Yes indeed - this is a very good benefit, particularly as we extend the capabilities with more data like NUMA / migration / etc. At some point I think it'd be interesting to do a similar refactoring for domains. So we could have an internal virDomainDefPtr to store the definitions and a generic XML formatter / XML parser shared by all drivers. Yes I think that has been on the back of everybody's mind since the beginning, but we were not confident enough in the set of properties doing it internally would be good, then at some point we may even expose it in the API, but there is no hurry. On the other hand cleaning up the domain code mess (incredible how simple things become complex as the code is extended) with new internal structures and APIs in the same way would be a really great thing. But that should probably wait a little bit I feel we are too close to the next release for this, Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [PATCH 1/2] Add internal API for managing capabilities data
On Tue, Feb 26, 2008 at 08:24:53AM -0500, Daniel Veillard wrote: On Tue, Feb 26, 2008 at 12:52:32PM +, Daniel P. Berrange wrote: On Tue, Feb 26, 2008 at 09:39:49AM +, Richard W.M. Jones wrote: Yes, this all looks good. Another advantage of doing this is that we can be sure that the capabilities XML generated by each driver will have the same schema. Yes indeed - this is a very good benefit, particularly as we extend the capabilities with more data like NUMA / migration / etc. At some point I think it'd be interesting to do a similar refactoring for domains. So we could have an internal virDomainDefPtr to store the definitions and a generic XML formatter / XML parser shared by all drivers. Yes I think that has been on the back of everybody's mind since the beginning, but we were not confident enough in the set of properties doing it internally would be good, then at some point we may even expose it in the API, but there is no hurry. Yes, if we keep the structs internal we can still change it at will. At worst we'd get compile errors for the drivers which could be trivially fixed. On the other hand cleaning up the domain code mess (incredible how simple things become complex as the code is extended) with new internal structures and APIs in the same way would be a really great thing. But that should probably wait a little bit I feel we are too close to the next release for this, Absolutely - i wasn't suggesting that we do it right now - there's plenty of other things to worry about first :-) The existing qemud_conf.h file contains a reasonable starting point for internal VM API, but would need a fair bit more work to be generic enough for the container based drivers. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [PATCH 1/2] Add internal API for managing capabilities data
This patch adds the files src/capabilities.{c,h} providing an internal
API for dealing with capabilities data.
All the struct's defined in the header map 1-to-1 onto the structure of
the XML capabilities data. Since these definitions are internal only we
are not stuck with ABI constraints on them.
There are then 3 core sets of APIs:
- Registration: adding host features, migration transports, NUMA cells,
guest os types, guest domain types, and guest features
- Querying: determining if an OS type is supported, and getting config
params
- Formatting: turning the virCapsPtr object into an XML document
The implementation should be fairly self explanatory if you understand
the overall structure of the capabilities XML already.
NB, we don't call virRaiseError anywhere in this file - the only error that
can occur is OOM, so we let the caller raise VIR_ERR_NO_MEMORY with their
own specific context info.
Makefile.am|1
capabilities.c | 696 +
capabilities.h | 183 ++
3 files changed, 880 insertions(+)
Dan
Index: src/Makefile.am
===
RCS file: /data/cvs/libvirt/src/Makefile.am,v
retrieving revision 1.70
diff -u -p -r1.70 Makefile.am
--- src/Makefile.am 25 Feb 2008 13:55:56 - 1.70
+++ src/Makefile.am 26 Feb 2008 04:47:00 -
@@ -37,6 +37,7 @@ CLIENT_SOURCES =
\
test.c test.h \
buf.c buf.h\
qparams.c qparams.h \
+capabilities.c capabilities.h \
xml.c xml.h \
event.c event.h \
xen_unified.c xen_unified.h \
Index: src/capabilities.c
===
RCS file: src/capabilities.c
diff -N src/capabilities.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ src/capabilities.c 26 Feb 2008 04:47:00 -
@@ -0,0 +1,696 @@
+/*
+ * capabilities.c: hypervisor capabilities
+ *
+ * Copyright (C) 2006-2008 Red Hat, Inc.
+ * Copyright (C) 2006-2008 Daniel P. Berrange
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Author: Daniel P. Berrange [EMAIL PROTECTED]
+ */
+
+#include capabilities.h
+#include buf.h
+
+
+/**
+ * virCapabilitiesNew:
+ * @arch: host machine architecture
+ * @offlineMigrate: non-zero if offline migration is available
+ * @liveMigrate: non-zero if live migration is available
+ *
+ * Allocate a new capabilities object
+ */
+virCapsPtr
+virCapabilitiesNew(const char *arch,
+ int offlineMigrate,
+ int liveMigrate)
+{
+virCapsPtr caps;
+
+if ((caps = calloc(1, sizeof(*caps))) == NULL)
+goto no_memory;
+
+if ((caps-host.arch = strdup(arch)) == NULL)
+goto no_memory;
+caps-host.offlineMigrate = offlineMigrate;
+caps-host.liveMigrate = liveMigrate;
+
+return caps;
+
+ no_memory:
+virCapabilitiesFree(caps);
+return NULL;
+}
+
+static void
+virCapabilitiesFreeHostNUMACell(virCapsHostNUMACellPtr cell)
+{
+free(cell-cpus);
+free(cell);
+}
+
+static void
+virCapabilitiesFreeGuestDomain(virCapsGuestDomainPtr dom)
+{
+int i;
+free(dom-info.emulator);
+free(dom-info.loader);
+for (i = 0 ; i dom-info.nmachines ; i++)
+free(dom-info.machines[i]);
+free(dom-info.machines);
+
+free(dom);
+}
+
+static void
+virCapabilitiesFreeGuestFeature(virCapsGuestFeaturePtr feature)
+{
+free(feature-name);
+free(feature);
+}
+
+static void
+virCapabilitiesFreeGuest(virCapsGuestPtr guest)
+{
+int i;
+free(guest-ostype);
+
+free(guest-arch.defaultInfo.emulator);
+free(guest-arch.defaultInfo.loader);
+for (i = 0 ; i guest-arch.defaultInfo.nmachines ; i++)
+free(guest-arch.defaultInfo.machines[i]);
+free(guest-arch.defaultInfo.machines);
+
+for (i = 0 ; i guest-arch.ndomains ; i++)
+virCapabilitiesFreeGuestDomain(guest-arch.domains[i]);
+free(guest-arch.domains);
+
+for (i = 0 ; i
