[libvirt] [PATCH] news: Update release notes

[Daniel P. Berrangé]

On Thu, Mar 01, 2018 at 03:12:39PM +0100, Michal Privoznik wrote:
> On 03/01/2018 02:15 PM, Peter Krempa wrote:
> > On Thu, Mar 01, 2018 at 14:08:29 +0100, Michal Privoznik wrote:
> >> Signed-off-by: --help <mprivozn at redhat.com>
> > 
> > Hmm.
> > 
> >> ---
> >>  docs/news.xml | 102 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>  1 file changed, 102 insertions(+)
> >>
> >> diff --git a/docs/news.xml b/docs/news.xml
> >> index 86a0c8d18..53bf9a49c 100644
> >> --- a/docs/news.xml
> >> +++ b/docs/news.xml
> >> @@ -44,6 +44,28 @@
> >>            using the <code>cachetune</code> element in <code>cputune</code>.
> >>          </description>
> >>        </change>
> >> +      <change>
> >> +        <summary>
> >> +          Allow opening secondary drivers
> >> +        </summary>
> >> +        <description>
> >> +          Up until now it was possible to connect to only hypervisor drivers
> >> +          (e.g. qemu:///system, lxc:///, vbox:///system, and so on). The
> >> +          internal drivers (like network driver, node device driver, etc.) were
> >> +          hidden from users and users could use them only indirectly. Starting
> >> +          with this release new connection URIs are accepted. For instance
> >> +          network:///system, storage:///system and so on.
> >> +        </description>
> > 
> > Isn't this an internal change not really used for consumption of
> > clients?
> 
> Not really. Try it yourself:
> 
> virsh -c network:///system net-list --all

Yes, that's explicitly intended to be usable by mgmt apps too. It would be
useful to open the storage drivers in particular without a hypervisor, as
many mgmt apps do storage operations on nodes which are not virt hosts.


> >> +      <change>
> >> +        <summary>
> >> +          src: Enable building with GCC 8.0
> >> +        </summary>
> >> +        <description>
> >> +          GCC 8.0 added more warnings which found some genuine problems with our code.
> >> +        </description>
> > 
> > I'm not sure whether that improved anything. Also wasn't that gcc 7?
> 
> It added a lot of cases into our switches which are now safer. The
> problem with enums in switch() statements is we have to be 100% sure
> value fits into the enum. For instance:
> 
> int x = VIR_DOMAIN_DEVICE_LAST + 1;
> 
> switch ((virDomainDeviceType) x) {
>   ...
> }
> 
> is obviously problematic.
> And no, it's gcc 8.

Well yes & no. GCC complained about cases where we fell-through case:
statements, due to us not including enough cases. This caused me to
notice the more general problem with us not handling enum values which
didn't correspond to named constants.

So the general addition of case/default everywhere was not specifically
required by gcc 8. It is just something I chose todo to make us more
robust after realizing the implications of what gcc8 identified. The
warning flags we use to validate this have existed in ancient gcc versions.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|