[libvirt] [PATCH] qemu: undefine is not allowed during domain starting up
by Yi Wang
Start a domain whilst undefine it, if starting failed duing ProcessLaunch,
on which period qemu exited unexpectedly, the operation will lead to failure
of undefine the domain until libvirtd restarted. The reason is that libvirtd
will unlock vm during qemuProcessStart, qemuDomainUndefineFlags can get the
lock and set vm->persistent 0 but not remove the "active" domain.
Signed-off-by: Yi Wang <wang.yi59(a)zte.com.cn>
---
src/conf/domain_conf.h | 1 +
src/qemu/qemu_driver.c | 6 ++++++
src/qemu/qemu_process.c | 3 +++
3 files changed, 10 insertions(+)
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index af15ee8..f339f84 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -2468,6 +2468,7 @@ struct _virDomainObj {
virDomainSnapshotObjPtr current_snapshot;
bool hasManagedSave;
+ bool starting;
void *privateData;
void (*privateDataFreeFunc)(void *);
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 6568def..5d9acfc 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -7317,6 +7317,12 @@ qemuDomainUndefineFlags(virDomainPtr dom,
if (!(vm = qemuDomObjFromDomain(dom)))
return -1;
+ if (vm->starting) {
+ virReportError(VIR_ERR_OPERATION_INVALID,
+ "%s", _("cannot undefine during domain starting up"));
+ goto cleanup;
+ }
+
cfg = virQEMUDriverGetConfig(driver);
if (virDomainUndefineFlagsEnsureACL(dom->conn, vm->def) < 0)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 525521a..7b708be 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -5847,6 +5847,8 @@ qemuProcessStart(virConnectPtr conn,
if (!migrateFrom && !snapshot)
flags |= VIR_QEMU_PROCESS_START_NEW;
+ vm->starting = true;
+
if (qemuProcessInit(driver, vm, updatedCPU,
asyncJob, !!migrateFrom, flags) < 0)
goto cleanup;
@@ -5892,6 +5894,7 @@ qemuProcessStart(virConnectPtr conn,
ret = 0;
cleanup:
+ vm->starting = false;
qemuProcessIncomingDefFree(incoming);
return ret;
--
1.8.3.1
7 years, 2 months
[libvirt] [PATCH 0/8] qemu: Default to video type=virtio for machvirt
by Cole Robinson
This series aim is to change the qemu machvirt video type default to
virtio, but rather than continue to hack things into place in
domain_conf.c, this rearranges things to allow drivers to set a
video type default.
Patches 1-4 are small cleanups/improvements in this area
Patches 5-7 are the plumbing to allow drivers to set their own default
Patch 8 is the actual default change
https://bugzilla.redhat.com/show_bug.cgi?id=1404112
Cole Robinson (8):
qemu: parse: drop redundant video config
qemu: domain: Move some validation out of DeviceDefPostParse
qemu: annotate some VIDEO_TYPE enum switch
conf: add virDomainVideoDefNew
conf: domain: add VIDEO_TYPE_DEFAULT
conf: domain: move video type validation to DeviceDefValidate
qemu: Set default video type in qemu PostParse
qemu: Default to video type=virtio for machvirt
src/conf/domain_conf.c | 54 +++++++++++-------
src/conf/domain_conf.h | 2 +
src/libvirt_private.syms | 1 +
src/qemu/qemu_command.c | 7 +--
src/qemu/qemu_domain.c | 66 ++++++++++++++--------
src/qemu/qemu_domain_address.c | 1 +
src/qemu/qemu_monitor_json.c | 16 ++----
src/qemu/qemu_parse_command.c | 14 +----
src/qemu/qemu_process.c | 7 +--
src/vz/vz_sdk.c | 3 +-
tests/domaincapsschemadata/full.xml | 1 +
.../qemuxml2argv-aarch64-video-default.args | 24 ++++++++
.../qemuxml2argv-aarch64-video-default.xml | 17 ++++++
tests/qemuxml2argvtest.c | 6 ++
.../qemuxml2xmlout-aarch64-video-default.xml | 46 +++++++++++++++
tests/qemuxml2xmltest.c | 6 ++
16 files changed, 191 insertions(+), 80 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-video-default.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-video-default.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-aarch64-video-default.xml
--
2.13.0
7 years, 2 months
[libvirt] libvirt 3.5.0 locks
by Vasiliy Tolstov
Hi. I'm testing libvirt 3.5.0 and have many issues like this:
Jul 14 09:47:25 cn25 libvirtd[18820]: 2017-07-14 06:47:25.598+0000:
18841: error : qemuDomainObjBeginJobInternal:3872 : Timed out during
operation: cannot acquire state change lock (held by
remoteDispatchConnectGetAllDomainStats)
Jul 14 09:47:25 cn25 libvirtd[18820]: 2017-07-14 06:47:25.598+0000:
18841: warning : qemuDomainObjBeginJobInternal:3860 : Cannot start job
(query, none) for domain 147565; current job is (query, none) owned by
(18828 remoteDispatchConnectGetAllDomainStats, 0 <null>) for (53670s,
0s)
Jul 14 09:46:55 cn25 libvirtd[18820]: 2017-07-14 06:46:55.576+0000:
18836: error : virNetDevTapInterfaceStats:751 : internal error:
/proc/net/dev: Interface not found
Jul 14 09:46:55 cn25 libvirtd[18820]: 2017-07-14 06:46:55.542+0000:
18832: warning : qemuGetProcessInfo:1428 : cannot parse process status
data
Jul 14 09:46:31 cn25 libvirtd[18820]: 2017-07-14 06:46:31.050+0000:
18838: warning : qemuGetProcessInfo:1428 : cannot parse process status
data
Domain in status in shutdown
as i see tap device already removed from the system, so
virNetDevTapInterfaceStats says right info.
My question - why lock now released and why only libvirt restart can
helps in this case
--
Vasiliy Tolstov,
e-mail: v.tolstov(a)selfip.ru
7 years, 3 months
[libvirt] [PATCH v2] vz: support disabled items in vz boot order
by Nikolay Shirokovskiy
At the time the check was written virtuozzo did not use disabled items in boot
order configuration. Boot items were always enabled. Now they can be disabled
as well. Supporting such items is easy - they just should be ignored.
---
src/vz/vz_sdk.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/src/vz/vz_sdk.c b/src/vz/vz_sdk.c
index 8ccd7ea..a6eb0dd 100644
--- a/src/vz/vz_sdk.c
+++ b/src/vz/vz_sdk.c
@@ -1736,11 +1736,8 @@ prlsdkConvertBootOrderVm(PRL_HANDLE sdkdom, virDomainDefPtr def)
pret = PrlBootDev_IsInUse(bootDev, &inUse);
prlsdkCheckRetGoto(pret, cleanup);
- if (!inUse) {
- virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
- _("Boot ordering with disabled items is not supported"));
- goto cleanup;
- }
+ if (!inUse)
+ continue;
pret = PrlBootDev_GetSequenceIndex(bootDev, &bootIndex);
prlsdkCheckRetGoto(pret, cleanup);
--
1.8.3.1
7 years, 3 months
[libvirt] [PATCH v2] qemu: command: align disk serial check to schema
by Nikolay Shirokovskiy
Disk serial schema has extra '.+' allowed characters in comparison
with check in code. Looks like there is no reason for that as qemu
allows any character AFAIK for serial. This discrepancy is originated
in 85d15b51 where ability to add serial was added.
---
Diff from v1:
* fix xml2argv disk serial test to use all valid chars
Looks like there is no existing infrastructure to test every invalid character.
src/qemu/qemu_command.c | 2 +-
tests/qemuxml2argvdata/qemuxml2argv-disk-serial.args | 2 +-
tests/qemuxml2argvdata/qemuxml2argv-disk-serial.xml | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index c76f923..c5369b0 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -432,7 +432,7 @@ qemuBuildIoEventFdStr(virBufferPtr buf,
}
#define QEMU_SERIAL_PARAM_ACCEPTED_CHARS \
- "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_ "
+ "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_ .+"
static int
qemuSafeSerialParamValue(const char *value)
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-serial.args b/tests/qemuxml2argvdata/qemuxml2argv-disk-serial.args
index 2cefdca..fa0fc93 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-disk-serial.args
+++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-serial.args
@@ -18,6 +18,6 @@ QEMU_AUDIO_DRV=none \
-boot c \
-usb \
-drive 'file=/dev/HostVG/QEMUGuest1,format=raw,if=none,id=drive-ide0-0-1,\
-serial=\ \ WD-WMAP9A966149' \
+serial=abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_\ .+' \
-device ide-drive,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-serial.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-serial.xml
index 565462e..d54d73b 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-disk-serial.xml
+++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-serial.xml
@@ -17,7 +17,7 @@
<disk type='block' device='disk'>
<source dev='/dev/HostVG/QEMUGuest1'/>
<target dev='hda' bus='ide'/>
- <serial> WD-WMAP9A966149</serial>
+ <serial>abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_ .+</serial>
<address type='drive' controller='0' bus='0' target='0' unit='1'/>
</disk>
<controller type='usb' index='0'/>
--
1.8.3.1
7 years, 3 months
[libvirt] [PATCH 0/5] A few fixes and improvements to the nodedev driver
by Erik Skultety
These are just the few I came across when working on another nodedev-related
series.
Erik Skultety (5):
nodedev: mdev: Report an error when virFileResolveLink fails
nodedev: udev: Remove the udevEventHandleCallback on fatal error
nodedev: Clear the udev_monitor reference once unref'd
nodedev: Introduce udevHandleOneDevice
nodedev: Protect every access to udev_monitor by locking the driver
src/node_device/node_device_udev.c | 59 +++++++++++++++++++++++++++-----------
1 file changed, 42 insertions(+), 17 deletions(-)
--
2.13.3
7 years, 3 months
[libvirt] [PATCH v2 00/20] Make the virNetworkObjPtr private
by John Ferlan
v1: https://www.redhat.com/archives/libvir-list/2017-May/msg00701.html
(but reviewed much more recently)
NOTE from v1:
Patches 1-3 already pushed
Former patch 4:
* Patch 1 (NEW) - splits out the formatting change in bridge_driver.h
* Patch 2 - Remainder of the change for consistent naming
NB: Without the split, there was a R-B, but I didn't push so that the
split could be "seen".
Former patch 5:
* Patch 3 (NEW) - from review create virMacMapFileName in src/util/virmacmap.c
* Patch 4 - Remainder of the previous change w/ adjusted name of course
* Patch 5 (NEW) - from review, alter virNetworkObjUnrefMacMap
Former patch 6:
* Patch 6 - No change
Former patch 7:
* Patch 7 (NEW) - Split out the @class_id to @classIdMap change
* Patch 8 - Remainder of previous change
Former patch 8:
* Patch 9 - No change
Former patch 9:
* Patch 10 - Make suggested naming adjustments
Add/use virNetworkObjSetDef API
Former patch 10:
* Patch 11 - Move code back to driver, just have accessors for @autostart
Former patch 11:
* Patch 12 - No change
Former patch 12:
* Patch 13 - Use virNetworkObjIsPersistent in networkSetAutostart
Former patch 13:
* Patch 14 - No change
Former patch 14:
* Patch 15 - Just have the virNetworkObjNew lock the object now and make
use of that with using virNetworkObjEndAPI in networkxml2conftest
NB: Since we'll have a refcnt=1 and lock=true after New the
EndAPI is proper
* Patch 16 (NEW) - Just move the virObjectRef - makes it clearer why it's
being ref'd
Former patch 15:
* Patch 17 (NEW) - Split out the rename of @nnames to @maxnames and explain
the reason better
* Patch 18 (NEW) - Split out the rename of @filter to @aclnames and explain
the reason better
* Patch 19 - The remainder of the former patch
Former patch 16:
* Patch 20 - No change (other than merge conflict resolution)
John Ferlan (20):
network: Perform some formatting cleanup in bridge_driver.h
network: Use consistent naming in bridge_driver for virNetwork objects
network: Move and rename networkMacMgrFileName
network: Move macmap mgmt from bridge_driver to virnetworkobj
network: Unconditionally initialize macmap when stopping virtual
network
network: Add virNetworkObj Get/Set API's for @dnsmasqPid and @radvdPid
network: Alter virNetworkObj @class_id to be @classIdMap
network: Introduce virNetworkObjGetClassIdMap
network: Add virNetworkObj Get/Set API's for @floor_sum
network: Add virNetworkObj Get/Set API's for @def and @newDef
network: Introduce virNetworkObj{Get|Set}Autostart
network: Introduce virNetworkObj{Is|Set}Active
network: Introduce virNetworkObjIsPersistent
network: Consistent use of @obj for virnetworkobj
network: Have virNetworkObjNew lock the returned object
network: Move virObjectRef during AssignDef processing
network: Use @maxnames instead of @nnames
network: Rename @filter to @aclfilter
network: Modify naming for virNetworkObjList* fetching APIs
network: Privatize virNetworkObj
src/conf/virnetworkobj.c | 614 +++++++++++++++-------
src/conf/virnetworkobj.h | 105 ++--
src/libvirt_private.syms | 21 +
src/network/bridge_driver.c | 1218 ++++++++++++++++++++++---------------------
src/network/bridge_driver.h | 50 +-
src/test/test_driver.c | 83 +--
src/util/virmacmap.c | 12 +
src/util/virmacmap.h | 4 +
tests/networkxml2conftest.c | 11 +-
9 files changed, 1231 insertions(+), 887 deletions(-)
--
2.9.4
7 years, 3 months
[libvirt] [PATCH] qemu: Fix bug assuming usage of default UUID for certificate passphrase
by John Ferlan
If an environment specific _tls_x509_cert_dir is provided, then
do not VIR_STRDUP the defaultTLSx509secretUUID as that would be
for the "default" environment and not the vnc, spice, chardev, or
migrate environments. If the environment needs a secret to decode
it's certificate, then it must provide the secret. If the secrets
happen to be the same, then configuration would use the same UUID
as the default (but we cannot assume that nor can we assume that
the secret would be necessary).
Signed-off-by: John Ferlan <jferlan(a)redhat.com>
---
While responding to a different patch today regarding Veritas and
usage of a default environment w/ or w/o secrets I realized that
the existing logic has a flaw in "assuming" that someone would want
to use the default secret. What if they defined their own environment
without a secret? Then the code would create a secret object to pass
to QEMU which would think it needs to use it to decode the server
certificate (but it doesn't), so it would seemingly fail the start.
I assume based on the lack of complaints about this that everyone just
uses the default environment!
src/qemu/qemu_conf.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index c4714ed..a7a2aaa 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -526,14 +526,18 @@ int virQEMUDriverConfigLoadFile(virQEMUDriverConfigPtr cfg,
goto cleanup; \
if (rv == 0) \
cfg->val## TLSx509verify = cfg->defaultTLSx509verify; \
- if (virConfGetValueString(conf, #val "_tls_x509_cert_dir", \
- &cfg->val## TLSx509certdir) < 0) \
+ if ((rv = virConfGetValueString(conf, #val "_tls_x509_cert_dir", \
+ &cfg->val## TLSx509certdir)) < 0) \
goto cleanup; \
if (virConfGetValueString(conf, \
#val "_tls_x509_secret_uuid", \
&cfg->val## TLSx509secretUUID) < 0) \
goto cleanup; \
- if (!cfg->val## TLSx509secretUUID && \
+ /* Only if a *tls_x509_cert_dir wasn't found (e.g. rv == 0), should \
+ * we copy the defaultTLSx509secretUUID. If this environment needs \
+ * a passphrase to decode the certificate, then it should provide \
+ * it's own secretUUID for that. */ \
+ if (rv == 0 && !cfg->val## TLSx509secretUUID && \
cfg->defaultTLSx509secretUUID) { \
if (VIR_STRDUP(cfg->val## TLSx509secretUUID, \
cfg->defaultTLSx509secretUUID) < 0) \
--
2.9.4
7 years, 3 months
[libvirt] [PATCHv2 0/3] exposing busy polling support for vhost-net
by sferdjao＠redhat.com
From: Sahid Orentino Ferdjaoui <sahid.ferdjaoui(a)redhat.com>
In version 2.7.0, QEMU introduced support of busy polling for
vhost-net [0]. To avoid paraphrasing original authors of that feature
and the purpose it I prefer to share a pointer [1].
This patch serie exposes throught the NIC driver-specific element a
new option 'poll_us'. That option is only available with the backend
driver 'vhost' and that because libvirt automatically fallback to QEMU
if the driver is not specified where that option is not available.
The option 'poll_us' takes a positive. 0 means that the option
is not going to be exposed.
[0] 69e87b32680a41d9761191443587c595b6f5fc3f
[1] https://lists.gnu.org/archive/html/qemu-devel/2016-11/msg04595.html
Sahid Orentino Ferdjaoui (3):
qemu: detect support for vhost-net busy polling
conf: introduce 'poll_us' attribute for domain interface
This patch finalizes support of 'poll_us' attribute as an option of
the NIC driver-specific element, the commit also takes care of
hotplug.
docs/formatdomain.html.in | 12 +++++++-
docs/schemas/domaincommon.rng | 5 ++++
src/conf/domain_conf.c | 16 +++++++++++
src/conf/domain_conf.h | 1 +
src/qemu/qemu_capabilities.c | 5 ++++
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 28 ++++++++++++++++++
src/qemu/qemu_hotplug.c | 12 ++++++++
tests/qemucapabilitiesdata/caps_2.7.0.s390x.xml | 1 +
tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml | 1 +
tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml | 1 +
tests/qemucapabilitiesdata/caps_2.8.0.x86_64.xml | 1 +
tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml | 1 +
.../qemuxml2argv-net-virtio-netdev-pollus-fail.xml | 23 +++++++++++++++
...xml2argv-net-virtio-netdev-pollus-qemu-fail.xml | 23 +++++++++++++++
.../qemuxml2argv-net-virtio-netdev-pollus.args | 25 ++++++++++++++++
.../qemuxml2argv-net-virtio-netdev-pollus.xml | 23 +++++++++++++++
.../qemuxml2argv-net-virtio-poll-us.xml | 23 +++++++++++++++
tests/qemuxml2argvtest.c | 9 ++++++
.../qemuxml2xmlout-net-virtio-poll-us.xml | 33 ++++++++++++++++++++++
tests/qemuxml2xmltest.c | 1 +
21 files changed, 244 insertions(+), 1 deletion(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-net-virtio-netdev-pollus-fail.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-net-virtio-netdev-pollus-qemu-fail.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-net-virtio-netdev-pollus.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-net-virtio-netdev-pollus.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-net-virtio-poll-us.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-net-virtio-poll-us.xml
--
2.9.4
7 years, 3 months
[libvirt] [PATCH v2 0/6] nwfilter adjustments for common object
by John Ferlan
v1: https://www.redhat.com/archives/libvir-list/2017-June/msg00079.html
Changes since v1 (if I can recall all of them!):
Patches 1, 4, 8-13 were pushed
Patches 2, 3, 5-7 are dropped
This this is a rework of patches 14-17
Patch 1 (former patch14):
* Requested adjustments made to ACK'd patch, but since this and the
remaining ones were related I didn't yet push it.
Patch 2 (new):
* From review though... As it turns out, virNWFilterDefEqual doesn't
require the @cmpUUIDs patch.
Patch 3 (fromer patch 15):
* Fixed the line as requested. Patch was ACK'd by like Patch 1 I held
onto it since it was related.
Patch 4 (former patch 16):
* Let's call it a complete rewrite. Rather than rely solely on the
refcnt of the object, I've added/implemented a 'trylock' mechanism
which essentially will allow the subsequent patch to use the
virObjectLockable (e.g. a non recursive lock). Of course as I got
further into the code - I think I've come to the conclusion that
there isn't a way for a @def to disappear between threads with a
refcnt only mechanism because there's a few other serialized locks
which would need to be hurdled before hand. Still as I found out
while running the Avocado test 'nwfilter_update_vm_running.update_arp_rule'
the recursion would occur because the AssignDef code would call the
Instantiation with the lock from the def being updated and that's
where all the awful magic needs to occur. Additionally, I found that
one wouldn't want to attempt to lock the nwfilters list inside the
virNWFilterObjListFindInstantiateFilter because AssignDef already
had that lock. I debated needing a recursive lock there until I
came to the conclusion that the list couldn't change because the
DefineXML is protected by a driver level lock (as is the Undefine
and Reload paths).
Patch 5 (former patch 17):
* No changes, it was ACK'd, but without 1-4 is useless
Patch 6 (NEW):
* Remove the need for the driver level lock for a few API's since
we have self locking nwfilters list. Also left comments in the
3 places where that lock remained to hopefully cause someone great
anxiety if they decided to attempt to remove the lock without
first consulting a specialist.
NB: Ran all of the changes through the 'nwfilter' tests found in
the Avocado test suite.
John Ferlan (6):
nwfilter: Add @refs logic to __virNWFilterObj
nwfilter: Remove unnecessary UUID comparison bypass
nwfilter: Convert _virNWFilterObjList to be a virObjectLockable
nwfilter: Remove recursive locking for nwfilter instantiation
nwfilter: Convert virNWFilterObj to use virObjectLockable
nwfilter: Remove need for nwfilterDriverLock in some API's
src/conf/virnwfilterobj.c | 635 ++++++++++++++++++++++++---------
src/conf/virnwfilterobj.h | 12 +-
src/libvirt_private.syms | 6 +-
src/nwfilter/nwfilter_driver.c | 66 ++--
src/nwfilter/nwfilter_gentech_driver.c | 66 +++-
src/util/virobject.c | 24 ++
src/util/virobject.h | 4 +
src/util/virthread.c | 5 +
src/util/virthread.h | 1 +
9 files changed, 586 insertions(+), 233 deletions(-)
--
2.9.4
7 years, 3 months
