[libvirt] [PATCHv3] util: make it more robust to calculate timeout value
From: Zhang Bo
When we change system clock to years ago, a certain CPU may use up 100% cputime.
The reason is that in function virEventPollCalculateTimeout(), we assign the
unsigned long long result to an INT variable,
*timeout = then - now; // timeout is INT, and then/now are long long
if (*timeout < 0)
*timeout = 0;
there's a chance that variable @then minus variable @now may be a very large
number
that overflows INT value expression, then *timeout will be negative and be
assigned to 0.
Next the 'poll' in function virEventPollRunOnce() will get into an 'endless'
while loop there.
thus, the cpu that virEventPollRunOnce() thread runs on will go up to 100%.
Although as we discussed before in
https://www.redhat.com/archives/libvir-list/2015-May/msg00400.html
it should be prohibited to set-time while other applications are running, but
it does
seems to have no harm to make the codes more robust.
Signed-off-by: Wang Yufei
Signed-off-by: Zhang Bo
---
src/util/vireventpoll.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/util/vireventpoll.c b/src/util/vireventpoll.c
index ffda206..4e4f407 100644
--- a/src/util/vireventpoll.c
+++ b/src/util/vireventpoll.c
@@ -357,9 +357,10 @@ static int virEventPollCalculateTimeout(int *timeout)
return -1;
EVENT_DEBUG("Schedule timeout then=%llu now=%llu", then, now);
-*timeout = then - now;
-if (*timeout < 0)
+if (then <= now)
*timeout = 0;
+else
+*timeout = ((then-now) > INT_MAX) ? INT_MAX : (then-now);
} else {
*timeout = -1;
}
--
1.7.12.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] libxl: load on FreeBSD
Martin Kletzander wrote: > On Sat, May 23, 2015 at 09:15:08PM +0300, Roman Bogorodskiy wrote: > >The libxl tries to check if it's running in dom0 by parsing > >/proc/xen/capabilities and if that fails it doesn't load. > > > >There's no procfs interface in Xen on FreeBSD, so this check always > >fails. > > > >Instead of using procfs, check if /dev/xen/xenstored, that's enough to > >check if we're running in dom0 in FreeBSD case. > > > >-- > > > >The 'HYPERVISOR_CAPABILITIES' name could be misleading now, however, I'd > >prefer to use a common variable to avoid duplicating of the file checking > >code. Maybe it should be renamed to something like HYPERVISOR_CONTROL? > > You can just add new one, XENSTORED for example, and check whether at > least one exists, reading the file afterwards if it is the old one. > It might not be FreeBSD-specific. What's your opinion? My concern was doing a check that will always fail on FreeBSD. Anyway, the check doesn't seem to be very expensive and happens only once, so it doesn't make any noticeable impact. I've sent v2. I hope it doesn't break existing behaviour on Linux. Roman Bogorodskiy pgpq4UjcSI4Af.pgp Description: PGP signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v2] libxl: load on FreeBSD
The libxl tries to check if it's running in dom0 by parsing
/proc/xen/capabilities and if that fails it doesn't load.
There's no procfs interface in Xen on FreeBSD, so this check always
fails.
In addition to checking procfs, check if /dev/xen/xenstored, that's enough to
check if we're running in dom0 in FreeBSD case.
---
src/libxl/libxl_driver.c | 42 ++
1 file changed, 22 insertions(+), 20 deletions(-)
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index 12be816..fddafa1 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -74,6 +74,7 @@ VIR_LOG_INIT("libxl.libxl_driver");
#define LIBXL_CONFIG_FORMAT_SEXPR "xen-sxpr"
#define HYPERVISOR_CAPABILITIES "/proc/xen/capabilities"
+#define HYPERVISOR_XENSTORED "/dev/xen/xenstored"
/* Number of Xen scheduler parameters */
#define XEN_SCHED_CREDIT_NPARAM 2
@@ -427,8 +428,6 @@ static bool
libxlDriverShouldLoad(bool privileged)
{
bool ret = false;
-int status;
-char *output = NULL;
/* Don't load if non-root */
if (!privileged) {
@@ -436,24 +435,27 @@ libxlDriverShouldLoad(bool privileged)
return ret;
}
-if (!virFileExists(HYPERVISOR_CAPABILITIES)) {
-VIR_INFO("Disabling driver as " HYPERVISOR_CAPABILITIES
- " does not exist");
-return ret;
-}
-/*
- * Don't load if not running on a Xen control domain (dom0). It is not
- * sufficient to check for the file to exist as any guest can mount
- * xenfs to /proc/xen.
- */
-status = virFileReadAll(HYPERVISOR_CAPABILITIES, 10, &output);
-if (status >= 0)
-status = strncmp(output, "control_d", 9);
-VIR_FREE(output);
-if (status) {
-VIR_INFO("No Xen capabilities detected, probably not running "
- "in a Xen Dom0. Disabling libxenlight driver");
-
+if (virFileExists(HYPERVISOR_CAPABILITIES)) {
+int status;
+char *output = NULL;
+/*
+ * Don't load if not running on a Xen control domain (dom0). It is not
+ * sufficient to check for the file to exist as any guest can mount
+ * xenfs to /proc/xen.
+ */
+status = virFileReadAll(HYPERVISOR_CAPABILITIES, 10, &output);
+if (status >= 0)
+status = strncmp(output, "control_d", 9);
+VIR_FREE(output);
+if (status) {
+VIR_INFO("No Xen capabilities detected, probably not running "
+ "in a Xen Dom0. Disabling libxenlight driver");
+
+return ret;
+}
+} else if (!virFileExists(HYPERVISOR_XENSTORED)) {
+VIR_INFO("Disabling driver as neither " HYPERVISOR_CAPABILITIES
+ " nor " HYPERVISOR_CAPABILITIES " exist");
return ret;
}
--
2.3.7
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Allow PCI virtio on ARM "virt" machine
Virt machine in qemu has PCI generic host controller, and can use PCI devices.
This
provides performance improvement as well as vhost-net with irqfd support for
virtio-net.
However libvirt still insists on virtio devices attached to Virt machine to
have MMIO
bindings.
This patch allows to use both. If the user doesn't specify ,
PCI will be used by default.
"virt-" prefix is intentionally ignored in third chunk because it is a
temporary thing
and qemu developers agreed to use "gic version" option, for which there is
already support
in libvirt.
---
src/qemu/qemu_command.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 81e89fc..0580a37 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -457,7 +457,7 @@ qemuDomainSupportsNicdev(virDomainDefPtr def,
/* non-virtio ARM nics require legacy -net nic */
if (((def->os.arch == VIR_ARCH_ARMV7L) ||
(def->os.arch == VIR_ARCH_AARCH64)) &&
-net->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_MMIO)
+strcmp(net->model, "virtio"))
return false;
return true;
@@ -1374,9 +1374,7 @@ qemuDomainAssignARMVirtioMMIOAddresses(virDomainDefPtr
def,
{
if (((def->os.arch == VIR_ARCH_ARMV7L) ||
(def->os.arch == VIR_ARCH_AARCH64)) &&
-(STRPREFIX(def->os.machine, "vexpress-") ||
-STREQ(def->os.machine, "virt") ||
-STRPREFIX(def->os.machine, "virt-")) &&
+STRPREFIX(def->os.machine, "vexpress-") &&
virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VIRTIO_MMIO)) {
qemuDomainPrimeVirtioDeviceAddresses(
def, VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_MMIO);
@@ -2501,6 +2499,12 @@ qemuAssignDevicePCISlots(virDomainDefPtr def,
VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW)
continue;
+ if (((def->os.arch == VIR_ARCH_ARMV7L) ||
+ (def->os.arch == VIR_ARCH_AARCH64)) &&
+ STREQ(def->os.machine, "virt") &&
+ def->disks[i]->info.type ==
VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_MMIO)
+ continue;
+
if (def->disks[i]->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
_("virtio disk cannot have an address of type
'%s'"),
--
1.9.5.msysgit.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] docs: Document new RO repo mirrors
On 05/23/2015 01:52 AM, Michal Privoznik wrote: > In the upstream discussion on creating a github mirror [1], it turned > out that there are some read-only mirrors of our repository. Lets > advertise them on our downloads page. But do it wisely and discourage > people in sending a pull requests on GitHub. > > 1: https://www.redhat.com/archives/libvir-list/2015-May/msg00775.html > > Signed-off-by: Michal Privoznik > --- > docs/downloads.html.in | 14 ++ > 1 file changed, 14 insertions(+) > > diff --git a/docs/downloads.html.in b/docs/downloads.html.in > index 435c2f1..a0ef7e6 100644 > --- a/docs/downloads.html.in > +++ b/docs/downloads.html.in > @@ -71,6 +71,20 @@ > > href="http://libvirt.org/git/?p=libvirt.git;a=summary";>http://libvirt.org/git/?p=libvirt.git;a=summary > > + > + In addition to this repository, there are following read-only s/there are/there are the/ s/read-only/read-only git/ [ok, department of redundancy department ;-)] > + repositories which mirror the master one. Note that we currently may > not colloquial "we" - But it's already used once... s/may/do > + be using the full set of features on these mirrors (e.g. pull requests > on > + GitHub, please don't use them). We want the discussion and patch review > + to happen at one place - on the list. Also note that some repositories s/please don't/so please don't/ s/We want ... on the list./All patch review and discussion only occurs on the libvir-list mailing list. / [just trying to point people at where to find this list - since the contact.html page has the list - I'd rather not duplicate the links] > + listed below allows HTTP checkouts too. s/allows/allow/ ACK - John > + > + > + > + href="https://github.com/libvirtproject/libvirt";>https://github.com/libvirtproject/libvirt > + href="http://repo.or.cz/w/libvirt.git";>http://repo.or.cz/w/libvirt.git > + href="https://gitlab.com/libvirt/libvirt";>https://gitlab.com/libvirt/libvirt > + > > > libvirt Application Development Guide > -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 4/4] storage: fs: Only force directory permissions if required
On 05/21/2015 04:03 PM, Cole Robinson wrote: > Only set directory permissions at pool build time, if: > > - User explicitly requested a mode via the XML > - The directory needs to be created > - We need to do the crazy NFS root-squash workaround > > This allows qemu:///session to call build on an existing directory > like /tmp. > --- > v3: > Minor code clarity tweaks > Drop an unused variable while I'm here > > src/storage/storage_backend_fs.c | 29 ++--- > src/util/virfile.c | 4 ++-- > 2 files changed, 20 insertions(+), 13 deletions(-) > ACK John -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 3/4] conf: storage: Don't emit empty block
On 05/21/2015 04:03 PM, Cole Robinson wrote: > --- > v3: > New patch > > src/conf/storage_conf.c| 42 > +- > tests/storagepoolxml2xmlout/pool-netfs-gluster.xml | 2 -- > tests/storagevolxml2xmlout/vol-gluster-dir.xml | 2 -- > tests/storagevolxml2xmlout/vol-sheepdog.xml| 2 -- > 4 files changed, 26 insertions(+), 22 deletions(-) > ACK - although I suppose it could be combined with 2/4, but I'm OK with it being separate. John -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 2/4] storage: conf: Don't set any default in the XML
On 05/21/2015 04:03 PM, Cole Robinson wrote:
> The XML parser sets a default if none is explicitly passed in.
> This is then used at pool/vol creation time, and unconditionally reported
> in the XML.
>
> The problem with this approach is that it's impossible for other code
> to determine if the user explicitly requested a storage mode. There
> are some cases where we want to make this distinction, but we currently
> can't.
>
> Handle parsing like we handle /: if no value is
> passed in, set it to -1, and adjust the internal consumers to handle
> it.
> ---
> v3:
> Drop needless test churn
> Add docs about default
>
> docs/formatstorage.html.in | 4 +++
> docs/schemas/storagecommon.rng | 8 +++--
> src/conf/storage_conf.c| 34
> +-
> src/storage/storage_backend.c | 20 +
> src/storage/storage_backend.h | 3 ++
> src/storage/storage_backend_fs.c | 9 --
> src/storage/storage_backend_logical.c | 4 ++-
> tests/storagepoolxml2xmlout/pool-netfs-gluster.xml | 1 -
> tests/storagevolxml2xmlout/vol-gluster-dir.xml | 1 -
> tests/storagevolxml2xmlout/vol-sheepdog.xml| 1 -
> 10 files changed, 51 insertions(+), 34 deletions(-)
>
> diff --git a/docs/formatstorage.html.in b/docs/formatstorage.html.in
> index f07bb5d..ccde978 100644
> --- a/docs/formatstorage.html.in
> +++ b/docs/formatstorage.html.in
> @@ -406,6 +406,8 @@
> namespace. It provides information about the permissions to use for
> the
> final directory when the pool is built. The
> mode element contains the octal permission set.
> +If mode is unset when creating a directory,
> +the value 0755 is used.
Consider "The mode defaults to 0755 when not provided."
The verbiage "is unset" reads strangly
> The owner element contains the numeric user ID.
> The group element contains the numeric group ID.
> If owner or group aren't specified when
> @@ -595,6 +597,8 @@
> files. For pools where the volumes are device nodes, the hotplug
> scripts determine permissions. It contains 4 child elements. The
> mode element contains the octal permission set.
> +If mode is unset when creating a supported volume,
> +the value 0600 is used.
ditto but 0600
Also, wherever you "point" the "
to should be whichever default is correct for the backing store. that is
from patch 1, you indicated that the elements are the same as one of
these two elements, so to be technically correct be sure to redirect to
either the 0755 or 0600 for which the backing store element would
default to if not provided.
ACK
John
> The owner element contains the numeric user ID.
> The group element contains the numeric group ID.
> If owner or group aren't specified when
> diff --git a/docs/schemas/storagecommon.rng b/docs/schemas/storagecommon.rng
> index 6f7d369..7c04462 100644
> --- a/docs/schemas/storagecommon.rng
> +++ b/docs/schemas/storagecommon.rng
> @@ -98,9 +98,11 @@
>
>
>
> -
> -
> -
> +
> +
> +
> +
> +
>
>
>
> diff --git a/src/conf/storage_conf.c b/src/conf/storage_conf.c
> index ee6e0cf..a02e504 100644
> --- a/src/conf/storage_conf.c
> +++ b/src/conf/storage_conf.c
> @@ -50,9 +50,6 @@
>
> VIR_LOG_INIT("conf.storage_conf");
>
> -#define DEFAULT_POOL_PERM_MODE 0755
> -#define DEFAULT_VOL_PERM_MODE 0600
> -
> VIR_ENUM_IMPL(virStorageVol,
>VIR_STORAGE_VOL_LAST,
>"file", "block", "dir", "network", "netdir")
> @@ -718,8 +715,7 @@ virStoragePoolDefParseSourceString(const char *srcSpec,
> static int
> virStorageDefParsePerms(xmlXPathContextPtr ctxt,
> virStoragePermsPtr perms,
> -const char *permxpath,
> -int defaultmode)
> +const char *permxpath)
> {
> char *mode;
> long long val;
> @@ -730,7 +726,7 @@ virStorageDefParsePerms(xmlXPathContextPtr ctxt,
> node = virXPathNode(permxpath, ctxt);
> if (node == NULL) {
> /* Set default values if there is not element */
> -perms->mode = defaultmode;
> +perms->mode = (mode_t) -1;
> perms->uid = (uid_t) -1;
> perms->gid = (gid_t) -1;
> perms->label = NULL;
> @@ -740,10 +736,7 @@ virStorageDefParsePerms(xmlXPathContextPtr ctxt,
> relnode = ctxt->node;
> ctxt->node = node;
>
> -mode = virXPathString("string(./mode)", ctxt);
> -if (!mode) {
> -perms->mode = defaultmode;
> -} else {
> +if ((mode = virXPathString("string(./mode)", ctxt))) {
> int tmp;
>
> if (virStrToLong_i(mode, NULL, 8, &tmp)
Re: [libvirt] [PATCH v3 1/4] docs: formatstorage: Update docs
On 05/21/2015 04:03 PM, Cole Robinson wrote: > - Don't redocument the permissions fields for backingstore, just point to > the volume docs. > - Clarify that owner/group are inherited from the parent directory at > volume create/pool build time. > - Clarify that fields report runtime values too > --- > v3: > New patch > For some reason - I sent it too quick... > docs/formatstorage.html.in | 36 ++-- > 1 file changed, 22 insertions(+), 14 deletions(-) > > diff --git a/docs/formatstorage.html.in b/docs/formatstorage.html.in > index 474abd6..f07bb5d 100644 > --- a/docs/formatstorage.html.in > +++ b/docs/formatstorage.html.in > @@ -405,11 +405,17 @@ > pools, which are mapped as a directory into the local filesystem > namespace. It provides information about the permissions to use for > the > final directory when the pool is built. The > -mode element contains the octal permission set. The > -owner element contains the numeric user ID. The > group > -element contains the numeric group ID. The label element > -contains the MAC (eg SELinux) label string. > +mode element contains the octal permission set. > +The owner element contains the numeric user ID. > +The group element contains the numeric group ID. > +If owner or group aren't specified when > +creating a directory, the values are inherited from the parent > +directory. The label element contains the MAC (eg > SELinux) > +label string. > Since 0.4.1 > +For running directory or filesystem based pools, these fields > +will be filled with the values used by the existing directory. > +Since 1.2.16 > >timestamps >Provides timing information about the volume. Up to four > @@ -583,15 +589,20 @@ > volume format type value and the default pool format will be used. > Since 0.4.1 >permissions > - Provides information about the default permissions to use > + Provides information about the permissions to use > when creating volumes. This is currently only useful for directory > or filesystem based pools, where the volumes allocated are simple > files. For pools where the volumes are device nodes, the hotplug > scripts determine permissions. It contains 4 child elements. The > -mode element contains the octal permission set. The > -owner element contains the numeric user ID. The > group > -element contains the numeric group ID. The label element > -contains the MAC (eg SELinux) label string. > +mode element contains the octal permission set. > +The owner element contains the numeric user ID. > +The group element contains the numeric group ID. > +If owner or group aren't specified when > +creating a supported volume, the values are inherited from the parent > +directory. The label element contains the MAC (eg > SELinux) > +label string. > +For existing directory or filesystem based volumes, these fields > +will be filled with the values used by the existing file. I was trying to note these two lines don't have the like the ... and they should probably be moved after the following to be consistent. > Since 0.4.1 > >compat > @@ -659,11 +670,8 @@ > Since 0.6.0 >permissions >Provides information about the permissions of the backing file. > -It contains 4 child elements. The > -mode element contains the octal permission set. The > -owner element contains the numeric user ID. The > group > -element contains the numeric group ID. The label element > -contains the MAC (eg SELinux) label string. > + See volume permissions documentation for explanation > + of individual fields. It's too bad the formatstorage.html doesn't have the section tags like a few other places so an href could point one at the or the ACK John > Since 0.6.0 > > > -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 1/4] docs: formatstorage: Update docs
On 05/21/2015 04:03 PM, Cole Robinson wrote: > - Don't redocument the permissions fields for backingstore, just point to > the volume docs. > - Clarify that owner/group are inherited from the parent directory at > volume create/pool build time. > - Clarify that fields report runtime values too > --- > v3: > New patch > > docs/formatstorage.html.in | 36 ++-- > 1 file changed, 22 insertions(+), 14 deletions(-) > > diff --git a/docs/formatstorage.html.in b/docs/formatstorage.html.in > index 474abd6..f07bb5d 100644 > --- a/docs/formatstorage.html.in > +++ b/docs/formatstorage.html.in > @@ -405,11 +405,17 @@ > pools, which are mapped as a directory into the local filesystem > namespace. It provides information about the permissions to use for > the > final directory when the pool is built. The > -mode element contains the octal permission set. The > -owner element contains the numeric user ID. The > group > -element contains the numeric group ID. The label element > -contains the MAC (eg SELinux) label string. s/.$/. There are 4 child elements. > +mode element contains the octal permission set. > +The owner element contains the numeric user ID. > +The group element contains the numeric group ID. > +If owner or group aren't specified when > +creating a directory, the values are inherited from the parent > +directory. The label element contains the MAC (eg > SELinux) > +label string. > Since 0.4.1 > +For running directory or filesystem based pools, these fields > +will be filled with the values used by the existing directory. > +Since 1.2.16 > >timestamps >Provides timing information about the volume. Up to four > @@ -583,15 +589,20 @@ > volume format type value and the default pool format will be used. > Since 0.4.1 >permissions > - Provides information about the default permissions to use > + Provides information about the permissions to use > when creating volumes. This is currently only useful for directory > or filesystem based pools, where the volumes allocated are simple > files. For pools where the volumes are device nodes, the hotplug > scripts determine permissions. It contains 4 child elements. The s/It contains /There are/ > -mode element contains the octal permission set. The > -owner element contains the numeric user ID. The > group > -element contains the numeric group ID. The label element > -contains the MAC (eg SELinux) label string. > +mode element contains the octal permission set. > +The owner element contains the numeric user ID. > +The group element contains the numeric group ID. > +If owner or group aren't specified when > +creating a supported volume, the values are inherited from the parent > +directory. The label element contains the MAC (eg > SELinux) > +label string. > +For existing directory or filesystem based volumes, these fields > +will be filled with the values used by the existing file. ^^^ the used above for 1.2.16 ^^^ the used above for 1.2.16 > Since 0.4.1 > >compat > @@ -659,11 +670,8 @@ > Since 0.6.0 >permissions >Provides information about the permissions of the backing file. > -It contains 4 child elements. The > -mode element contains the octal permission set. The > -owner element contains the numeric user ID. The > group > -element contains the numeric group ID. The label element > -contains the MAC (eg SELinux) label string. > + See volume permissions documentation for explanation > + of individual fields. > Since 0.6.0 > > > -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/3] Patches for a couple of Coverity errors
On 05/13/2015 12:32 PM, John Ferlan wrote: > The first one is one I forgot the last time I sent Coverity patches a > few weeks ago. The next two are from changes made recently. > > > John Ferlan (3): > storage: Resolve Coverity FORWARD_NULL > conf: Resolve Coverity FORWARD_NULL > network: Resolve Coverity FORWARD_NULL > > src/conf/domain_conf.c | 2 ++ > src/network/bridge_driver.c| 2 +- > src/storage/storage_backend_disk.c | 2 +- > 3 files changed, 4 insertions(+), 2 deletions(-) > Adjusted 2/3 to move the sa_assert after the virObjectLock and pushed the first 3. There are still 4/3 and 5/3 waiting for ACK's - those came from changes after this first series was on list. thanks for the reviews - John -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] zfs: fix storagepoolxml2xml test
Martin Kletzander wrote: > On Sat, May 23, 2015 at 10:49:09PM +0300, Roman Bogorodskiy wrote: > >Commit c4d27bd dropped output of owner/group -1. > > > >Update zfs tests accordingly. > >--- > > tests/storagepoolxml2xmlout/pool-zfs-sourcedev.xml | 2 -- > > tests/storagepoolxml2xmlout/pool-zfs.xml | 2 -- > > 2 files changed, 4 deletions(-) > > > > ACK Pushed, thanks! Roman Bogorodskiy pgpx93kUNMdrW.pgp Description: PGP signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] bhyve: fix build with gcc48
Eric Blake wrote:
> On 05/23/2015 02:45 PM, Martin Kletzander wrote:
> > On Sat, May 23, 2015 at 08:05:23PM +0300, Roman Bogorodskiy wrote:
> >> Build with gcc 4.8 fails with:
>
> Arguably a bug in gcc; but since we can work around it without too much
> pain, we should.
>
> >>
> >> bhyve/bhyve_monitor.c: In function 'bhyveMonitorIO':
>
> >> bhyveMonitorIO(int watch, int kq, int events ATTRIBUTE_UNUSED, void
> >> *opaque)
> >> {
> >> -const struct timespec zerowait = {};
> >> +const struct timespec zerowait = { 0, 0 };
>
> Would also be sufficient to do 'zerowait = { 0 };' - any C compiler that
> warns about an initializer of { 0 } is broken, because that is THE
> idiomatic way to zero-initialize anything (scalar or structure)
> according to C99.
>
> >
> > You "need" to set at least minimum one field, all others will be set
> > to 0. But this is of course very right thing to do.
> >
> > ACK, structures shouldn't be initialized this way.
>
> Go ahead and push as you have it, though, with two members, since we
> know struct timespec has (at least) two members.
Pushed, thanks!
Roman Bogorodskiy
pgpPA5xOzLb6o.pgp
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
