[libvirt PATCH 0/2] cpu_conf: Format vendor_id for host-model CPUs
by Jiri Denemark
In commit v5.9.0-400-gaf8e39921a I removed printing model's fallback and
vendor_id attributes when no model is specified. However, vendor_id
makes sense even without a specific CPU model (for host-model CPUs).
https://bugzilla.redhat.com/show_bug.cgi?id=1804549
Jiri Denemark (2):
qemuxml2xmltest: Add case for host-model vendor_id
cpu_conf: Format vendor_id for host-model CPUs
src/conf/cpu_conf.c | 14 +++++----
.../cpu-host-model-vendor.xml | 30 +++++++++++++++++++
tests/qemuxml2xmltest.c | 1 +
3 files changed, 40 insertions(+), 5 deletions(-)
create mode 100644 tests/qemuxml2xmloutdata/cpu-host-model-vendor.xml
--
2.25.0
4 years, 10 months
[PATCH] qemuDomainGetStatsIOThread: Don't leak array with 0 iothreads
by Peter Krempa
qemuMonitorGetIOThreads returns a NULL terminated list even when 0
iothreads are present. The caller didn't perform cleanup if there were 0
iothreads leaking the array.
https://bugzilla.redhat.com/show_bug.cgi?id=1804548
Reported-by: Jing Yan <jiyan(a)redhat.com>
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
---
src/qemu/qemu_driver.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index f686b858cf..39e1f044e0 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -21759,8 +21759,12 @@ qemuDomainGetStatsIOThread(virQEMUDriverPtr driver,
if ((niothreads = qemuDomainGetIOThreadsMon(driver, dom, &iothreads)) < 0)
return -1;
- if (niothreads == 0)
- return 0;
+ /* qemuDomainGetIOThreadsMon returns a NULL-terminated list, so we must free
+ * it even if it returns 0 */
+ if (niothreads == 0) {
+ ret = 0;
+ goto cleanup;
+ }
if (virTypedParamListAddUInt(params, niothreads, "iothread.count") < 0)
goto cleanup;
--
2.24.1
4 years, 10 months
virtlogd spinning on 100% CPU with the latest libvirt
by Richard W.M. Jones
Build libvirt from git (ccf7567329f).
Using the libvirt ‘run’ script, run something like
libguestfs-test-tool. I think basically any command which runs a
guest will do. NB These commands are all run as NON-root:
killall libvirtd lt-libvirtd virtlogd lt-virtlogd
./build/run libguestfs-test-tool
Now there will be a lt-virtlogd process using 100% of CPU:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2572972 rjones 20 0 47880 16256 14516 R 100.0 0.1 0:19.27 lt-virt+
$ ls /proc/2572972/fd -l
total 0
lrwx------. 1 rjones rjones 64 Feb 17 17:45 0 -> /dev/null
lrwx------. 1 rjones rjones 64 Feb 17 17:45 1 -> /dev/null
lr-x------. 1 rjones rjones 64 Feb 17 17:45 11 -> /var/lib/sss/mc/passwd
lr-x------. 1 rjones rjones 64 Feb 17 17:45 12 -> /var/lib/sss/mc/group
lrwx------. 1 rjones rjones 64 Feb 17 17:45 13 -> 'socket:[48299994]'
lr-x------. 1 rjones rjones 64 Feb 17 17:45 14 -> 'pipe:[48299995]'
l-wx------. 1 rjones rjones 64 Feb 17 17:45 16 -> /home/rjones/.cache/libvirt/qemu/log/guestfs-xllxycje1blj4nmd.log
l-wx------. 1 rjones rjones 64 Feb 17 17:45 17 -> /run/systemd/inhibit/1620.ref
lrwx------. 1 rjones rjones 64 Feb 17 17:45 2 -> /dev/null
lrwx------. 1 rjones rjones 64 Feb 17 17:45 3 -> 'socket:[48299981]'
l-wx------. 1 rjones rjones 64 Feb 17 17:45 4 -> /run/user/1000/libvirt/virtlogd.pid
lrwx------. 1 rjones rjones 64 Feb 17 17:45 5 -> 'socket:[48299984]'
lrwx------. 1 rjones rjones 64 Feb 17 17:45 6 -> 'socket:[48299986]'
lr-x------. 1 rjones rjones 64 Feb 17 17:45 7 -> 'pipe:[48299988]'
l-wx------. 1 rjones rjones 64 Feb 17 17:45 8 -> 'pipe:[48299988]'
lrwx------. 1 rjones rjones 64 Feb 17 17:45 9 -> 'anon_inode:[eventfd]'
$ ls -ltr /home/rjones/.cache/libvirt/qemu/log/guestfs-xllxycje1blj4nmd.log
-rw-------. 1 rjones rjones 4003 Feb 17 17:44 /home/rjones/.cache/libvirt/qemu/log/guestfs-xllxycje1blj4nmd.log
Only one thread running with this stack trace:
Thread 1 (Thread 0x7fa51f219b40 (LWP 2572972)):
#0 virObjectGetLockableObj (anyobj=0x55fb2896c200) at ../../src/util/virobject.c:393
#1 virObjectLock (anyobj=0x55fb2896c200) at ../../src/util/virobject.c:427
#2 0x00007fa520fda48f in virNetServerHasClients (srv=0x55fb2896c200) at ../../src/rpc/virnetserver.c:966
#3 0x00007fa520fd7b69 in daemonServerHasClients (payload=<optimized out>, key=<optimized out>, opaque=0x7ffc8adb5a47) at ../../src/rpc/virnetdaemon.c:916
#4 0x00007fa520ea7140 in virHashForEach (data=<optimized out>, iter=<optimized out>, table=<optimized out>) at ../../src/util/virhash.c:639
#5 virHashForEach (table=0x55fb289571a0, iter=iter@entry=0x7fa520fd7b60 <daemonServerHasClients>, data=data@entry=0x7ffc8adb5a47) at ../../src/util/virhash.c:627
#6 0x00007fa520fd89ee in virNetDaemonHasClients (dmn=<optimized out>) at ../../src/rpc/virnetdaemon.c:927
#7 0x00007fa520fd8aa5 in virNetDaemonRun (dmn=0x55fb28957110) at ../../src/rpc/virnetdaemon.c:842
#8 0x000055fb27b5c8e9 in main (argc=<optimized out>, argv=0x7ffc8adb6188) at ../../src/logging/log_daemon.c:1153
pstack shows it's fairly busy and the stack trace is not very
consistent, eg:
#0 0x00007fa52032aaed in g_free () at /lib64/libglib-2.0.so.0
#1 0x00007fa520e73d1b in virFree (ptrptr=ptrptr@entry=0x55fb2896c1a8) at ../../src/util/viralloc.c:348
#2 0x00007fa520e982d2 in virResetError (err=0x55fb2896c1a0) at ../../src/util/virerror.c:472
#3 virResetError (err=0x55fb2896c1a0) at ../../src/util/virerror.c:468
#4 0x00007fa520e9963c in virEventRunDefaultImpl () at ../../src/util/virevent.c:341
#5 0x00007fa520fd8abd in virNetDaemonRun (dmn=0x55fb28957110) at ../../src/rpc/virnetdaemon.c:858
#6 0x000055fb27b5c8e9 in main (argc=<optimized out>, argv=0x7ffc8adb6188) at ../../src/logging/log_daemon.c:1153
#0 0x00007fa520184a37 in poll () at /lib64/libc.so.6
#1 0x00007fa520324e3e in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2 0x00007fa520324f73 in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3 0x00007fa520e9a4f0 in virEventGLibRunOnce () at ../../src/util/vireventglib.c:496
#4 0x00007fa520e99645 in virEventRunDefaultImpl () at ../../src/util/virevent.c:343
#5 0x00007fa520fd8abd in virNetDaemonRun (dmn=0x55fb28957110) at ../../src/rpc/virnetdaemon.c:858
#6 0x000055fb27b5c8e9 in main (argc=<optimized out>, argv=0x7ffc8adb6188) at ../../src/logging/log_daemon.c:1153
#0 0x00007fa520322d9d in g_source_ref () at /lib64/libglib-2.0.so.0
#1 0x00007fa520322e71 in g_source_iter_next () at /lib64/libglib-2.0.so.0
#2 0x00007fa52032479f in g_main_context_check () at /lib64/libglib-2.0.so.0
#3 0x00007fa520324de2 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#4 0x00007fa520324f73 in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#5 0x00007fa520e9a4f0 in virEventGLibRunOnce () at ../../src/util/vireventglib.c:496
#6 0x00007fa520e99645 in virEventRunDefaultImpl () at ../../src/util/virevent.c:343
#7 0x00007fa520fd8abd in virNetDaemonRun (dmn=0x55fb28957110) at ../../src/rpc/virnetdaemon.c:858
#8 0x000055fb27b5c8e9 in main (argc=<optimized out>, argv=0x7ffc8adb6188) at ../../src/logging/log_daemon.c:1153
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
4 years, 10 months
[libvirt PATCH] docs: reduce excessive spacing in ToC for RST files
by Daniel P. Berrangé
The table of contents in the RST based files uses <p> tags inside the
<li>, which results in 1em's worth of spacing above & below each
entry. This results in way too much whitespace in the ToC.
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
docs/libvirt.css | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/docs/libvirt.css b/docs/libvirt.css
index 2fe123395c..18e55dac59 100644
--- a/docs/libvirt.css
+++ b/docs/libvirt.css
@@ -579,3 +579,7 @@ ul.news-section-content li dl dd {
font-family: monospace;
background: #eeeeee;
}
+
+.contents li p {
+ margin: 2px;
+}
--
2.24.1
4 years, 10 months
[libvirt PATCH v2 0/6] qemu: add stricter checks of permissibility of the QoS parameter 'floor'
by Pavel Mores
v2 is mostly just integrating requests from Michal's review. The initial two
commits introduce new utility functions to be used in the following two
commits. The final two commits have no substantial changes since v1.
The only exception are long lines caused by error messages which stay unbroken
in v2 as per libvirt's contributor's guidelines (as was also pointed out during
review).
Pavel Mores (6):
qemu: test if bandwidth has 'floor' factored out to separate function
qemu: add function to test if network supports setting 'floor'
qemu: fail on attempt to set 'floor' if interface type is not
'network'
qemu: check if 'floor' is supported for given interface and network
qemu: call networkPlugBandwidth() for all types of network
docs: QoS parameter 'floor' is supported for 'open' networks too
docs/formatnetwork.html.in | 2 +-
src/conf/netdev_bandwidth_conf.h | 27 +++++++++++++++++++++++++++
src/network/bridge_driver.c | 27 +++++++++++++++++++--------
src/qemu/qemu_driver.c | 18 +++++++++++++++---
4 files changed, 62 insertions(+), 12 deletions(-)
--
2.24.1
4 years, 10 months
[PATCH v3 00/15] qemu: Handle 'size' and 'offset' attributes of 'raw' format
by Peter Krempa
This series fixes and improves the 'json:' pseudo-protocol parser and
implements the 'offset' and 'size' attributes and exposes them as
<slice> in the XML.
The previous version attempted an easy route, but that didn't cover all
cases. This version adds storage slice support for everything except
image creation.
https://bugzilla.redhat.com/show_bug.cgi?id=1791788
Peter Krempa (15):
qemu: domain: Refactor formatting of node names into status XML
docs: formatdomain: Close <source> on one of disk examples
tests: virstorage: Add test data for json specified raw image with
offset/size
util: virstoragefile: Add data structure for storing storage source
slices
qemuBlockStorageSourceGetFormatRawProps: format 'offset' and 'size'
for slice
qemuDomainValidateStorageSource: Reject unsupported slices
qemu: block: forbid creation of storage sources with <slice>
docs: Document the new <slices> sub-element of disk's <source>
conf: Implement support for <slices> of disk source
qemu: domain: Store nodenames of slice in status XML
qemu: block: Properly format storage slice into backing store strings
tests: qemublock: Add cases for creating image overlays on top of
disks with <slice>
qemu: Add support for slices of type 'storage'
tests: qemu: Add test data for the new <slice> element
virStorageSourceParseBackingJSONRaw: Parse 'offset' and 'size'
attributes
docs/formatdomain.html.in | 14 ++
docs/schemas/domaincommon.rng | 19 ++
src/conf/domain_conf.c | 86 +++++++++
src/qemu/qemu_block.c | 169 ++++++++++++++----
src/qemu/qemu_block.h | 4 +
src/qemu/qemu_blockjob.c | 1 +
src/qemu/qemu_command.c | 8 +
src/qemu/qemu_domain.c | 36 +++-
src/util/virstoragefile.c | 49 +++++
src/util/virstoragefile.h | 12 ++
tests/qemublocktest.c | 2 +
.../qcow2-backing-qcow2-slice.json | 15 ++
.../imagecreate/qcow2-backing-qcow2-slice.xml | 1 +
.../imagecreate/qcow2-backing-raw-slice.json | 15 ++
.../imagecreate/qcow2-backing-raw-slice.xml | 1 +
.../imagecreate/qcow2-slice.xml | 14 ++
.../imagecreate/raw-slice.xml | 14 ++
tests/qemustatusxml2xmldata/modern-in.xml | 4 +
.../disk-slices.x86_64-latest.args | 53 ++++++
tests/qemuxml2argvdata/disk-slices.xml | 45 +++++
tests/qemuxml2argvtest.c | 2 +
.../disk-slices.x86_64-latest.xml | 56 ++++++
tests/qemuxml2xmltest.c | 2 +
tests/virstoragetest.c | 13 ++
24 files changed, 590 insertions(+), 45 deletions(-)
create mode 100644 tests/qemublocktestdata/imagecreate/qcow2-backing-qcow2-slice.json
create mode 120000 tests/qemublocktestdata/imagecreate/qcow2-backing-qcow2-slice.xml
create mode 100644 tests/qemublocktestdata/imagecreate/qcow2-backing-raw-slice.json
create mode 120000 tests/qemublocktestdata/imagecreate/qcow2-backing-raw-slice.xml
create mode 100644 tests/qemublocktestdata/imagecreate/qcow2-slice.xml
create mode 100644 tests/qemublocktestdata/imagecreate/raw-slice.xml
create mode 100644 tests/qemuxml2argvdata/disk-slices.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/disk-slices.xml
create mode 100644 tests/qemuxml2xmloutdata/disk-slices.x86_64-latest.xml
--
2.24.1
4 years, 10 months
[libvirt PATCH v2] docs: add news item about gnulib removal
by Daniel P. Berrangé
While we have CI testing coverage for many platforms, we don't test any
non-glibc based Linux and there are other non-Linux platforms we don't
officially target, both of which might hit regressions.
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
docs/news.xml | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/docs/news.xml b/docs/news.xml
index 5aa9d081a7..13812a1234 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -97,6 +97,25 @@
</section>
<section title="Bug fixes">
</section>
+ <section title="Packaging changes">
+ <change>
+ <summary>
+ use of gnulib has been completely eliminated
+ </summary>
+ <description>
+ Historically libvirt has embedded gnulib to provide fixes for
+ various platform portability problems. This usage has now been
+ eliminated and alternative approaches for platform portability
+ problems adopted where required. This has been validated on the
+ set of platforms covered by automated CI build testing. Other
+ modern Linux distros using glibc are expected to work. Linux
+ distros using non-glibc packages, and other non-Linux platforms
+ may encounter regressions when building this release. Please
+ report any build problems encountered back to the project
+ maintainers for evaluation.
+ </description>
+ </change>
+ </section>
</release>
<release version="v6.0.0" date="2020-01-15">
<section title="Packaging changes">
--
2.24.1
4 years, 10 months
[rust PATCH] Implement virStoragePoolListAllVolumes and virStoragePoolListVolumes for StoragePool
by mathias＠pius.io
From: Mathias Pius <mathias(a)pius.io>
Now as a single patch, and with Signed-off-by tag in accordance with DCO.
This patch implements virStoragePoolListAllVolumes and virStoragePoolListVolumes for the StoragePool object. I'm not too familiar with the libvirt codebase, so I've used similar functions from connect.rs and domain.rs for so the implementations should (hopefully) be as correct as those. I've taken the liberty of using Vec::with_capacity when allocating vectors to store the result of these operations in, to prevent reallocations while converting the object types from the internal type to StorageVol and Strings.
Signed-off-by: Mathias Pius <mathias(a)pius.io>
---
src/storage_pool.rs | 55 ++++++++++++++++++++++++++++++++++++++++++-
tests/storage_pool.rs | 34 ++++++++++++++++++++++++++
2 files changed, 88 insertions(+), 1 deletion(-)
diff --git a/src/storage_pool.rs b/src/storage_pool.rs
index 96258f0..571fabd 100644
--- a/src/storage_pool.rs
+++ b/src/storage_pool.rs
@@ -18,7 +18,7 @@
extern crate libc;
-use std::str;
+use std::{mem, ptr, str};
use connect::sys::virConnectPtr;
use storage_vol::sys::virStorageVolPtr;
@@ -78,6 +78,16 @@ extern "C" {
fn virStoragePoolFree(ptr: sys::virStoragePoolPtr) -> libc::c_int;
fn virStoragePoolIsActive(ptr: sys::virStoragePoolPtr) -> libc::c_int;
fn virStoragePoolIsPersistent(ptr: sys::virStoragePoolPtr) -> libc::c_int;
+ fn virStoragePoolListAllVolumes(
+ ptr: sys::virStoragePoolPtr,
+ vols: *mut *mut virStorageVolPtr,
+ flags: libc::c_uint,
+ ) -> libc::c_int;
+ fn virStoragePoolListVolumes(
+ ptr: sys::virStoragePoolPtr,
+ names: *mut *mut libc::c_char,
+ maxnames: libc::c_int,
+ ) -> libc::c_int;
fn virStoragePoolGetName(ptr: sys::virStoragePoolPtr) -> *const libc::c_char;
fn virStoragePoolGetXMLDesc(
ptr: sys::virStoragePoolPtr,
@@ -119,6 +129,8 @@ pub const VIR_STORAGE_POOL_RUNNING: StoragePoolState = 2;
pub const VIR_STORAGE_POOL_DEGRADED: StoragePoolState = 3;
pub const VIR_STORAGE_POOL_INACCESSIBLE: StoragePoolState = 4;
+pub type StoragePoolListAllVolumesFlags = self::libc::c_uint;
+
#[derive(Clone, Debug)]
pub struct StoragePoolInfo {
/// A `StoragePoolState` flags
@@ -373,6 +385,47 @@ impl StoragePool {
}
}
+ pub fn list_all_volumes(
+ &self,
+ flags: StoragePoolListAllVolumesFlags,
+ ) -> Result<Vec<StorageVol>, Error> {
+ unsafe {
+ let mut volumes: *mut virStorageVolPtr = ptr::null_mut();
+
+ let size =
+ virStoragePoolListAllVolumes(self.as_ptr(), &mut volumes, flags as libc::c_uint);
+ if size == -1 {
+ return Err(Error::new());
+ }
+
+ mem::forget(volumes);
+
+ let mut array: Vec<StorageVol> = Vec::with_capacity(size as usize);
+ for x in 0..size as isize {
+ array.push(StorageVol::new(*volumes.offset(x)));
+ }
+ libc::free(volumes as *mut libc::c_void);
+
+ Ok(array)
+ }
+ }
+
+ pub fn list_volumes(&self) -> Result<Vec<String>, Error> {
+ unsafe {
+ let mut names: [*mut libc::c_char; 1024] = [ptr::null_mut(); 1024];
+ let size = virStoragePoolListVolumes(self.as_ptr(), names.as_mut_ptr(), 1024);
+ if size == -1 {
+ return Err(Error::new());
+ }
+
+ let mut array: Vec<String> = Vec::with_capacity(size as usize);
+ for x in 0..size as usize {
+ array.push(c_chars_to_string!(names[x]));
+ }
+ return Ok(array);
+ }
+ }
+
pub fn refresh(&self, flags: u32) -> Result<u32, Error> {
unsafe {
let ret = virStoragePoolRefresh(self.as_ptr(), flags as libc::c_uint);
diff --git a/tests/storage_pool.rs b/tests/storage_pool.rs
index 4bfa71d..21c1139 100644
--- a/tests/storage_pool.rs
+++ b/tests/storage_pool.rs
@@ -58,3 +58,37 @@ fn test_lookup_storage_pool_by_name() {
}
common::close(c);
}
+
+#[test]
+fn test_list_volumes() {
+ match Connect::open("test:///default") {
+ Ok(mut conn) => {
+ let sp = conn.list_storage_pools().unwrap_or(vec![]);
+ match StoragePool::lookup_by_name(&conn, &sp[0]) {
+ Ok(storage_pool) => {
+ storage_pool.list_volumes().unwrap();
+ }
+ Err(e) => panic!("failed with code {}, message: {}", e.code, e.message),
+ }
+ assert_eq!(0, conn.close().unwrap_or(-1));
+ }
+ Err(e) => panic!("failed with code {}, message: {}", e.code, e.message),
+ }
+}
+
+#[test]
+fn test_list_all_volumes() {
+ match Connect::open("test:///default") {
+ Ok(mut conn) => {
+ let sp = conn.list_storage_pools().unwrap_or(vec![]);
+ match StoragePool::lookup_by_name(&conn, &sp[0]) {
+ Ok(storage_pool) => {
+ storage_pool.list_all_volumes(0).unwrap();
+ }
+ Err(e) => panic!("failed with code {}, message: {}", e.code, e.message),
+ }
+ assert_eq!(0, conn.close().unwrap_or(-1));
+ }
+ Err(e) => panic!("failed with code {}, message: {}", e.code, e.message),
+ }
+}
--
2.25.0
4 years, 10 months
Questions about using qemuProcess API within a libvirt test
by Collin Walling
Hello,
I am working on implementing libvirt test cases for the hypervisor-cpu-compare
and -baseline commands. Ideally, I would like to take advantage of the
qemuProcess API to spin up a QEMU instance and run these commands to test real
data queried from the hypervisor. However, I am having issues with my libvirt
tests communicating with a QEMU instance. The API can successfully spin an
instance, but no commands can be sent to QEMU -- not even the qmp_capabilities
handshake. The test case hangs forever with no indication that something went
wrong.
The hang occurs specifically within the qemuProcessQMPLaunch phase of the
qemuProcessQMPStart function. Eventually the libvirt API will get to
qemuMonitorSend, and at this loop...
while (!mon->msg->finished) {
if (virCondWait(&mon->notify, &mon->parent.lock) < 0) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("Unable to wait on monitor condition"));
goto cleanup;
}
}
...the program will hang at conditional wait. I kept the QEMU instance alive
after killing my test and connected to the monitor socket that was still
lingering. The qmp_capabilities command was never sent, thus leading me to
believe that the libvirt tests cannot communicate with a QEMU instance.
As s390x is currently the only arch to have implemented these commands, I
believe it would be beneficial to have an easy way to test both the expected
QEMU response and libvirt parsing within a single test case if/when other archs
decide to implement these commands.
I'd like to ask two questions:
1: does it make sense for libvirt tests to communicate with an external binary
(specifically QEMU)?
2: if so, is there some sort of conflict between a libvirt test and a QEMU
binary? I afraid to say that I am at a loss how to repair this or perhaps how
to use the API properly.
I appreciate anyone's help with looking into this.
Note: in case I am not clear, by "libvirt test" I am referring to a test
implemented in the tests directory of the libvirt project.
--
Respectfully,
- Collin Walling
4 years, 10 months
[libvirt PATCH] docs: add news item about GNULIB removal
by Daniel P. Berrangé
While we have CI testing coverage for many platforms, we don't test any
non-GLibC based Linux and there are other non-Linux platforms we don't
officially target, both of which might hit regressions.
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
docs/news.xml | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/docs/news.xml b/docs/news.xml
index f567a1182e..54ccc31abe 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -84,6 +84,25 @@
</change>
</section>
<section title="Improvements">
+ <change>
+ <summary>
+ use of GNULIB has been completely eliminated
+ </summary>
+ <description>
+ Historically libvirt has embedded GNULIB to provide fixes for
+ various platform portability problems. This usage has now been
+ eliminated and alternative approaches for platform portability
+ problems adopted where required. This has been validated on the
+ set of platforms covered by automated CI build testing: Fedora
+ 30, 31 and rawhide; CentOS 7 and 8; Debian 9 and 10; Ubuntu 18.04;
+ FreeBSD 11 and 12; Mingw-w64; macOS 10.14 with XCode 10.3 and 11.3.
+ Other Linux distros of a similar vintage using GLibC are expected
+ to work. Linux distros using non-GLibC packages, and other
+ non-Linux platforms may encounter regressions when building this
+ release. Please report any build problems encountered back to the
+ project maintainers for resolution.
+ </description>
+ </change>
</section>
<section title="Bug fixes">
</section>
--
2.24.1
4 years, 10 months
