1. 14 10月, 2019 2 次提交
    • D
      util: rewrite auto cleanup macros to use glib's equivalent · 44e7f029
      Daniel P. Berrangé 提交于
      To facilitate porting over to glib, this rewrites the auto cleanup
      macros to use glib's equivalent.
      
      As a result it is now possible to use g_autoptr/VIR_AUTOPTR, and
      g_auto/VIR_AUTOCLEAN, g_autofree/VIR_AUTOFREE interchangably, regardless
      of which macros were used to declare the cleanup types.
      
      Within the scope of any single method, code must remain consistent
      using either GLib or Libvirt macros, never mixing both. New code
      must preferentially use the GLib macros, and old code will be
      converted incrementally.
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      44e7f029
    • D
      build: probe for glib-2 library in configure · 58e7c9bc
      Daniel P. Berrangé 提交于
      Prepare for linking with glib by probing for it at configure
      time. Per supported platforms target, the min glib versions on
      relevant distros are:
      
        RHEL-8: 2.56.1
        RHEL-7: 2.50.3
        Debian (Buster): 2.58.3
        Debian (Stretch): 2.50.3
        OpenBSD (Ports): 2.58.3
        FreeBSD (Ports): 2.56.3
        OpenSUSE Leap 15: 2.54.3
        SLE12-SP2: 2.48.2
        Ubuntu (Xenial): 2.48.0
        macOS (Homebrew): 2.56.0
      
      This suggests that a minimum glib of 2.48 is a reasonable target.
      This aligns with the minimum version required by qemu too.
      
      We must disable the bad-function-cast warning as various GLib APIs
      and macros will trigger this.
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      58e7c9bc
  2. 09 10月, 2019 1 次提交
  3. 08 10月, 2019 1 次提交
  4. 07 10月, 2019 2 次提交
  5. 19 9月, 2019 2 次提交
    • P
      Revert "configure: Colorize output" · 56c56b3b
      Peter Krempa 提交于
      The colors are not based on the semantics of the message but rather
      on the message itself. This means that the default human-perceived
      semantics (red = bad, green = good) don't really apply and spotting a
      color does not mean anythting.
      
      This is amplified by the sheer amount of output which configure produces
      and the fact that some of the messages have negative semantics or
      additional output.
      
      In case of any problem the user will have to go through everything
      anyways as spotting a red or yellow line has 0 information value.
      
      Here are a few examples:
      
      1) some 'no' messages are not a problem:
      
        checking minix/config.h presence... no
      
      2) some 'no' messages are actually positive:
      
        checking for special C compiler options needed for large files... no
      
      3) in some cases a 'yes' would mean that something is broken or needs
         workaround
      
        checking whether stat file-mode macros are broken... no
        checking whether wint_t is too small... no
        checking whether stdint.h predates C++11... no
        checking whether the inttypes.h PRIxNN macros are broken... no
        checking whether clang gives bogus warnings for -Wdouble-promotion... no
        checking whether gettimeofday clobbers localtime buffer... no
      
      4) due to string match based colors extra text makes messages yellow
      
        checking for a traditional french locale... none
        checking for working nanosleep... no (mishandles large arguments)
        checking for library containing gethostbyname... none required
        checking whether mbrtowc handles incomplete characters... (cached) guessing yes
      
      5) in some cases the yes/no is very context dependant
      
        checking whether pthread_rwlock_rdlock prefers a writer to a reader... no
        checking whether this build is done by a static analysis tool... no
      
      6) detected paths to binaries and libs are yellow despite being present
      
        checking for objdump... objdump
        checking for atomic ops implementation... gcc
      
      As of the reasons above I don't think the colorization of the configure
      output helps users or developers to debug the build process and
      thus is not worth the extra code or output clutter.
      
      This reverts commit c98174ce.
      ACKed-by: NMichal Prívozník <mprivozn@redhat.com>
      Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
      56c56b3b
    • P
      Revert "virt-result.m4: Colourize summary printings" · 1a1c293e
      Peter Krempa 提交于
      The colorization based on the string itself makes little to no sense as
      the semantic meaning of the color (red = bad, green = good) is not
      extracted from the semantics of the message:
      
      1) If there is some additional string a 'yes' is marked yellow:
      
      configure:       driver_modules: yes (CFLAGS='' LIBS='-ldl')
      
      2) In some cases a 'no' is actually good:
      
      configure:                  hal: no
      
      3) Few good/recommended configuration options are still yellow:
      
      configure:                 QEMU: qemu:qemu
      
      while using 'root:root' would still be yellow.
      
      4) fields dumping config (e.g. the warning flags line) is a giant blob
        of colored text which makes little sense
      
      configure:        Warning Flags:  -fno-common -W -Wabsolute-value
      -Waddress -Waddress-of-packed-member -Waggressive-loop-optimizations
      -Wall -Wattribute-warning -Wattributes -Wbad-function-cast
      -Wbool-compare -Wbool-operation -Wbuiltin-declaration-mismatch
      -Wbuiltin-macro-redefined -Wcannot-profile -Wcast-align
      -Wcast-align=strict -Wcast-function-type -Wchar-subscripts -Wclobbered
      -Wcomment -Wcomments -Wcoverage-mismatch -Wcpp -Wdangling-else
      -Wdate-time -Wdeprecated-declarations -Wdesignated-init
      -Wdiscarded-array-qualifiers -Wdiscarded-qualifiers -Wdiv-by-zero
      -Wdouble-promotion -Wduplicated-cond -Wduplicate-decl-speci ...
      
      In addition if the idea is to switch to a more usable build system it
      does not make sense to clutter the current one with more code.
      
      This reverts commit 4b3ab5d2.
      ACKed-by: NMichal Prívozník <mprivozn@redhat.com>
      Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
      1a1c293e
  6. 12 9月, 2019 4 次提交
  7. 06 9月, 2019 1 次提交
  8. 04 9月, 2019 1 次提交
  9. 12 8月, 2019 1 次提交
  10. 10 8月, 2019 1 次提交
    • D
      build: bump min libxml2 to 2.9.1 · e4c05240
      Daniel P. Berrangé 提交于
      The various distros have the following libxml2 vesions:
      
              CentOS 7: 2.9.1
        Debian Stretch: 2.9.4
         FreeBSD Ports: 2.9.9
      Ubuntu 16.04 LTS: 2.9.3
      
      Based on this sampling, we can reasonably bump libxml2 min
      version to 2.9.1
      
      The 'query_raw' struct field was added in version 2.6.28,
      so can be assumed to exist.
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      e4c05240
  11. 09 8月, 2019 1 次提交
    • D
      remote: enable connecting to the per-driver daemons · b18c273a
      Daniel P. Berrangé 提交于
      Historically URIs handled by the remote driver will always connect to
      the libvirtd UNIX socket. There will now be one daemon per driver, and
      each of these has its own UNIX sockets to connect to.
      
      It will still be possible to run the traditional monolithic libvirtd
      though, which will have the original UNIX socket path.
      
      In addition there is a virproxyd daemon that doesn't run any drivers,
      but provides proxying for clients accessing libvirt over IP sockets, or
      tunnelling to the legacy libvirtd UNIX socket path.
      
      Finally when running inside a daemon, the remote driver must not reject
      connections unconditionally. For example, the QEMU driver needs to be
      able to connect to the network driver. The remote driver must thus be
      willing to handle connections even when inside the daemon, provided no
      local driver is registered.
      
      This refactoring enables the remote driver to be able to connect to the
      per-driver daemons. The URI parameter "mode" accepts the values "auto",
      "direct" and "legacy" to control which daemons are connected to.
      
      The client side libvirt.conf config file also supports a "remote_mode"
      setting which is used if the URI parameter is not set.
      
      If neither the config file or URI parameter set a mode, then "auto"
      is used, whereby the client looks to see which sockets actually exist
      right now.
      
      The remote driver will only ever spawn the per-driver daemons, or
      the legacy libvirtd. It won't ever try to spawn virtproxyd, as
      that is only there for IP based connectivity, or for access from
      legacy remote clients.
      
      If connecting to a remote host over any kind of ssh tunnel, for now we
      must assume only the legacy socket exists. A future patch will introduce
      a netcat replacement that is tailored for libvirt to make remote
      tunnelling easier.
      
      The configure arg '--with-remote-default-mode=legacy|direct' allows
      packagers to set a default at build time. If not given, it will default
      to legacy mode.
      
      Eventually the default will switch to direct mode. Distros can choose
      to do the switch earlier if desired. The main blocker is testing and
      suitable SELinux/AppArmor policies.
      Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      b18c273a
  12. 07 8月, 2019 1 次提交
  13. 08 7月, 2019 1 次提交
  14. 21 6月, 2019 2 次提交
    • D
      remote: delete the avahi mDNS support · 5a148ce8
      Daniel P. Berrangé 提交于
      Libvirtd has long had integration with avahi for advertising libvirtd
      using mDNS when TCP/TLS listening is enabled. For a long time the
      virt-manager application had support for auto-detecting libvirtds
      on the local network using mDNS, but this was removed last year
      
        commit fc8f8d5d7e3ba80a0771df19cf20e84a05ed2422
        Author: Cole Robinson <crobinso@redhat.com>
        Date:   Sat Oct 6 20:55:31 2018 -0400
      
          connect: Drop avahi support
      
          Libvirtd can advertise itself over avahi. The feature is disabled by
          default though and in practice I hear of no one actually using it
          and frankly I don't think it's all that useful
      
          The 'Open Connection' wizard has a disproportionate amount of code
          devoted to this feature, but I don't think it's useful or worth
          maintaining, so let's drop it
      
      I've never heard of any other applications having support for using
      mDNS to detect libvirtd instances. Though it is theoretically possible
      something exists out there, it is clearly going to be a niche use case
      in the virt ecosystem as a whole.
      
      By removing avahi integration we can cut down the dependency chain for
      the basic libvirtd install and reduce our code maint burden.
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      5a148ce8
    • P
      rpc: virnetlibsshsession: update deprecated functions · e0ce339c
      Pavel Hrdina 提交于
      In libssh 0.9.0 functions ssh_is_server_known and ssh_write_knownhost
      are marked as deprecated.
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1722735Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
      e0ce339c
  15. 17 5月, 2019 3 次提交
  16. 16 5月, 2019 2 次提交
  17. 15 5月, 2019 1 次提交
  18. 10 5月, 2019 1 次提交
  19. 15 4月, 2019 1 次提交
  20. 12 4月, 2019 7 次提交
  21. 03 4月, 2019 3 次提交
  22. 27 3月, 2019 1 次提交