[libvirt] [PATCH 00/23] Take 64 gnulib modules, eliminate 14, to give 50 remaining

Daniel P. Berrangé berrange at redhat.com
Fri Jan 3 11:22:20 UTC 2020


On Thu, Jan 02, 2020 at 05:40:22PM +0100, Fabiano Fidêncio wrote:
> Daniel,
> 
> On Thu, Jan 2, 2020 at 3:59 PM Daniel P. Berrangé <berrange at redhat.com> wrote:
> >
> > In the last days before the xmas break I took some time to
> > eliminate 14 more gnulib modules, bringing us down to just
> > 50 left to go. They're getting harder to eliminate as we go
> > on, but to give some hints, I've annotated every module in
> > bootstrap.conf with a suggested replacement strategy.
> >
> > Daniel P. Berrangé (23):
> >   build: set min version for CLang to 3.4 / XCode CLang to 5.1
> >   docs: expand macOS platform support coverage
> >   travis: add macOS Xcode 11.3 testing
> >   util: add note about event file descriptors on Windows
> >   src: always pull in glib/gstdio.h header
> >   src: switch to use g_setenv/g_unsetenv
> 
> In the patch above I'd also take the opportunity and use TRUE/FALSE
> instead of 1/0 in g_setenv().
> Feel free to ignore as this is just a minor nitpick;

Yes, it should use TRUE/FALSE to match the API parameter type.

> >   util: add compat wrapper for g_fsync
> >   src: use g_fsync for portability
> >   util: introduce virFileDataSync
> 
> What would be the impact of using g_fsync() on Linuxes as well?

fsync is stronger & so worse for performance

[quote fdatasync(2)]
       fdatasync()  is similar to fsync(), but does not flush modified metadata
       unless that metadata is needed in  order  to  allow  a  subsequent  data
       retrieval  to be correctly handled. 
       ...snip...
       The aim of fdatasync() is to reduce disk activity for applications  that
       do not require all metadata to be synchronized with the disk.
[/quote]

> 
> >   src: use g_lstat() instead of lstat()
> >   src: switch from fnmatch to g_pattern_match_simple
> 
> This one worries me a little bit about possible breakages, mainly
> related to wildcards used in libvirtd.conf.

Yes, there is a risk here, however, the config files are not part of the
API/ABI guarantee and the risk is reasonably low. It'll need a release
note of course.


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 :|




More information about the libvir-list mailing list