- Devel - libvirt List Archives

[libvirt] PATCH: Helper for enumerations
by Daniel P. Berrange 24 Jun '08

24 Jun '08

There are quite a few places in our code where we have to convert from a string to an int enumeration, and vica-verca. This is tedious code to write, and I'm about to introduce a tonne more enumerations in the new generic domain XML parser / generator. So I reckon its time for some helper APIs The current pattern is that we have an enumeration enum virStoragePoolDisk { VIR_STORAGE_POOL_DISK_DOS, VIR_STORAGE_POOL_DISK_DVH, VIR_STORAGE_POOL_DISK_GPT, VIR_STORAGE_POOL_DISK_MAC, VIR_STORAGE_POOL_DISK_BSD, VIR_STORAGE_POOL_DISK_PC98, VIR_STORAGE_POOL_DISK_SUN, }; And then 2 helpers static int virStorageBackendDiskPoolFormatFromString(const char *format) { if (STREQ(format, "dos")) return VIR_STORAGE_POOL_DISK_DOS; if (STREQ(format, "dvh")) return VIR_STORAGE_POOL_DISK_DVH; if (STREQ(format, "gpt")) return VIR_STORAGE_POOL_DISK_GPT; if (STREQ(format, "mac")) return VIR_STORAGE_POOL_DISK_MAC; if (STREQ(format, "bsd")) return VIR_STORAGE_POOL_DISK_BSD; if (STREQ(format, "pc98")) return VIR_STORAGE_POOL_DISK_PC98; if (STREQ(format, "sun")) return VIR_STORAGE_POOL_DISK_SUN; return -1; } static const char * virStorageBackendDiskPoolFormatToString(int format) { switch (format) { case VIR_STORAGE_POOL_DISK_DOS: return "dos"; case VIR_STORAGE_POOL_DISK_DVH: return "dvh"; case VIR_STORAGE_POOL_DISK_GPT: return "gpt"; case VIR_STORAGE_POOL_DISK_MAC: return "mac"; case VIR_STORAGE_POOL_DISK_BSD: return "bsd"; case VIR_STORAGE_POOL_DISK_PC98: return "pc98"; case VIR_STORAGE_POOL_DISK_SUN: return "sun"; } return NULL; } This patch adds 2 generic ToString and FromString methods to the util.c module, which take a list of strings, in the same order as the enum int virEnumFromString(const char *const*types, int ntypes, const char *type); const char *virEnumToString(const char *const*types, int ntypes, int type); Passing around the list of strings (the "char *const*types" arg) is a little tedious, so there are 2 macros to simplify this by defining wrappers around the virEnumXXX functions VIR_ENUM_DECL(name) will define the function prototypes, and should be used in a header file, while VIR_ENUM_IMPL(name, maxvals, types) will define the implementation, type checked at compile time So, going back to the earlier example - we need to adapt the enum to add a sentinal at the end enum virStoragePoolDisk { VIR_STORAGE_POOL_DISK_DOS, VIR_STORAGE_POOL_DISK_DVH, VIR_STORAGE_POOL_DISK_GPT, VIR_STORAGE_POOL_DISK_MAC, VIR_STORAGE_POOL_DISK_BSD, VIR_STORAGE_POOL_DISK_PC98, VIR_STORAGE_POOL_DISK_SUN, VIR_STORAGE_POOL_DISK_LAST }; Then, we can provide the ToString and FromString methods with just VIR_ENUM_DECL(virStoragePoolDisk) VIR_ENUM_IMPL(virStoragePoolDisk, VIR_STORAGE_POOL_DISK_LAST, "dos", "dvh", "gpt", "mac", "bsd", "pc98", "sun") This has compile time checking to ensure there are enough strings for every enumeration value. Daniel. diff -r bc1615919490 src/util.c --- a/src/util.c Fri Jun 13 15:43:20 2008 +0100 +++ b/src/util.c Fri Jun 13 18:52:39 2008 +0100 @@ -798,3 +798,24 @@ return idx; } +int virEnumFromString(const char *const*types, + int ntypes, + const char *type) +{ + int i; + for (i = 0 ; i < ntypes ; i++) + if (STREQ(types[i], type)) + return i; + + return -1; +} + +const char *virEnumToString(const char *const*types, + int ntypes, + int type) +{ + if (type < 0 || type >= ntypes) + return NULL; + + return types[type]; +} diff -r bc1615919490 src/util.h --- a/src/util.h Fri Jun 13 15:43:20 2008 +0100 +++ b/src/util.h Fri Jun 13 18:52:39 2008 +0100 @@ -25,6 +25,7 @@ #define __VIR_UTIL_H__ #include "util-lib.h" +#include "verify.h" int virExec(virConnectPtr conn, char **argv, int *retpid, int infd, int *outfd, int *errfd); @@ -88,4 +89,31 @@ int virDiskNameToIndex(const char* str); + +int virEnumFromString(const char *const*types, + int ntypes, + const char *type); + +const char *virEnumToString(const char *const*types, + int ntypes, + int type); + +#define VIR_ENUM_IMPL(name, lastVal, ...) \ + static const char const *name ## TypeList[] = { __VA_ARGS__ }; \ + verify(ARRAY_CARDINALITY(name ## TypeList) == lastVal); \ + const char *name ## TypeToString(int type) { \ + return virEnumToString(name ## TypeList, \ + ARRAY_CARDINALITY(name ## TypeList), \ + type); \ + } \ + int name ## TypeFromString(const char *type) { \ + return virEnumFromString(name ## TypeList, \ + ARRAY_CARDINALITY(name ## TypeList), \ + type); \ + } + +#define VIR_ENUM_DECL(name) \ + const char *name ## TypeToString(int type); \ + int name ## TypeFromString(const char*type); + #endif /* __VIR_UTIL_H__ */ -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

3 3

[libvirt] [PATCH 0 of 3] LXC network interface support
by Dan Smith 23 Jun '08

23 Jun '08

This set is actually authored by Dave Leskovec. He is moving on to some other work and I will be working this into the tree. I have made a few changes to this, mostly to allow this code to compile out if the proper kernel and userspace support is not present. I am submitting it as an RFC because the required kernel patches are not yet upstream (even in -mm) and there are some missing userspace patches to iproute2 as well. I expect there to be quite a few comments and suggestions about the veth.c patch, so I wanted to go ahead and get that started while we wait for upstream to catch up. Comments appreciated!

5 15

[Libvir] [PATCH] Fix USB device name mis-conversion from S-Expr to XML
by Hiroyuki Kaguchi 22 Jun '08

22 Jun '08

"tablet" and "mouse" are set as a value of the /local/domain/<domid>/image/hvm/usbdevice, but libvirt expects "usbdevice" and "usbmouse" as a value. This causes the following. If a USB device is attached by virt-manager, the USB device is not seen from virt-manager. This patch fixes expected value of libvirt Thanks, Hiroyuki Kaguchi Index: xend_internal.c =================================================================== RCS file: /data/cvs/libvirt/src/xend_internal.c,v retrieving revision 1.162 diff -u -r1.162 xend_internal.c --- xend_internal.c 21 Jan 2008 16:29:10 -0000 1.162 +++ xend_internal.c 23 Jan 2008 00:37:02 -0000 @@ -1743,11 +1743,9 @@ node = cur->u.s.car; if (sexpr_lookup(node, "usbdevice")) { tmp = sexpr_node(node, "usbdevice"); - if (tmp && *tmp) { - if (!strcmp(tmp, "usbtablet")) - virBufferAdd(&buf, " <input type='tablet' bus='usb'/>\n", 37); - else if (!strcmp(tmp, "usbmouse")) - virBufferAdd(&buf, " <input type='mouse' bus='usb'/>\n", 36); + if (!strcmp(tmp, "tablet") || + !strcmp(tmp, "mouse")) { + virBufferVSprintf(&buf, " <input type='%s' bus='usb'/>\n", tmp); } } }

3 4

[libvirt] [PATCH]: fix ruby-libvirt bindings when virConnectNum* returns 0
by Chris Lalancette 20 Jun '08

20 Jun '08

Attached is a simple patch to fix a problem I ran into when using the ruby-libvirt bindings with libvirt 0.4.3. Basically, if you call any of the virConnectList* functions with a "max" of 0, it returns "Invalid Arg". To get around this, modify the ruby-libvirt bindings to return an empty list if we get num == 0 when calling the corresponding virConnectNumOf* function. This should solve: https://bugzilla.redhat.com/show_bug.cgi?id=451666 Signed-off-by: Chris Lalancette <clalance(a)redhat.com>

3 4

[libvirt] libvirt passes wrong MAC address to KVM
by Nikola Ciprich 20 Jun '08

20 Jun '08

Hi all, I think there could be a bug in libvirt passing MAC address to KVM. If I have following in my xml config: <interface type="bridge"> <source bridge="br0"/> <mac address="00:16:3e:0d:24:00"/> </interface> and start the domain (I'm using python binding btw), qemu is then executed with following parameter: ... -net nic,macaddr=00:16:3e:18:24:00,vlan=0 ... MAC address given in config is not used by any other machine. Does somebody have a tip on where the problem could be? I'm using libvirt-0.4.3. Thanks in advance BR nik -- ------------------------------------- Nikola CIPRICH LinuxBox.cz, s.r.o. 28. rijna 168, 709 01 Ostrava tel.: +420 596 603 142 fax: +420 596 621 273 mobil: +420 777 093 799 www.linuxbox.cz mobil servis: +420 737 238 656 email servis: servis(a)linuxbox.cz -------------------------------------

2 4

[libvirt] Re: [Ovirt-devel] Updated libvirt 0.4.3 packages with fixes
by Alan Pevec 20 Jun '08

20 Jun '08

Alan Pevec wrote: > Chris Lalancette wrote: >> http://koji.fedoraproject.org/koji/taskinfo?taskID=670309 >> >> Please give them a whirl, and if you have problems, report them to me and >> libvir-devel. > > Although you didn't ask for positive reports, I can confirm that all > works fine with libvirt-0.4.3-1fixes installed on host machine, running > 'developer' and nodes built using it. One thing I forgot to mention: it works with SELinux in permissive mode (setenforce 0) I filed bz to modify selinux policy: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=452103 libvirt-0.4.3 needs set/getsched If you want SELinux in enforcing mode, bz has SELinux policy module attached which you can use until selinux policy is updated.

1 0

[libvirt] [PATCH] Fix XML escaping problem in the XM driver
by Daniel Veillard 19 Jun '08

19 Jun '08

Basically the XM driver when generating the XML config forgets to escape things like filepaths allowing characters which are forbidden as-is in XML instances to pass in the resulting config files which then are unusable. The patch also adds a new test checking the escaping is done in a few critical places. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

1 0

[libvirt] Test packages for various fixes
by Chris Lalancette 19 Jun '08

19 Jun '08

I've sent a build through koji that contains 0.4.3 + iSCSI fixes + VIR_ALLOC fixes + tapfd fixes for Fedora 9. It's available here, if you want to test: http://koji.fedoraproject.org/koji/taskinfo?taskID=670309 As usual, if there are any bugs that you find, please report them here. Chris Lalancette

1 0

[libvirt] [PATCH]: Fix allocation of tapfds when starting qemu
by Chris Lalancette 19 Jun '08

19 Jun '08

All, When doing the conversion to danpb's new memory API, a small bug was introduced into the qemudNetworkIfaceConnect() function. In particular, there is a call: if (VIR_ALLOC_N(vm->tapfds, vm->ntapfds+2) < 0) goto no_memory; However, the tapfds structure is used to track *all* of the tap fds, and is called once for each network that is being attached to the domain. VIR_ALLOC_N maps to calloc(). So the first network would work just fine, but if you had more than one network, subsequent calls to this function would blow away the stored fd's that were already there and fill them all in with zeros. This causes multiple problems, from the qemu domains not starting properly to improper cleanup on shutdown. The attached patch just changes the VIR_ALLOC_N() to a VIR_REALLOC_N(), and everything is happy again. Signed-off-by: Chris Lalancette <clalance(a)redhat.com>

4 7

[libvirt] [PATCH]: Fix VIR_ALLOC_N for 0 byte arrays
by Chris Lalancette 19 Jun '08

19 Jun '08

Hello, For 0.4.3, danpb's new memory management scheme went into libvirt. This is fine, except that is subtly alters the semantics of malloc(), calloc(), and realloc(). In particular, if you say: foo = malloc(0); glibc will happily return a non-NULL pointer to you. However, with the new memory management stuff, if you say: foo = VIR_ALLOC(0); you will actually get a NULL pointer back. Personally, I think this is a dangerous deviation from malloc() semantics that everyone is used to, and is indeed causing problems with the remote driver. The short of it is that the remote driver allocates memory on behalf of the remote side using VIR_ALLOC_N, and this call is returning NULL so that the NULL checks elsewhere in the code fire and return failure. The attached patch fixes this situation by removing the 0 checks from the memory allocation paths, and just lets them fall through to the normal malloc(), calloc(), or realloc() routines, restoring old semantics. Signed-off-by: Chris Lalancette <clalance(a)redhat.com>

4 3