Skip to content
Snippets Groups Projects
  1. Sep 10, 2020
  2. Jul 19, 2019
  3. Jun 01, 2018
  4. Nov 08, 2017
  5. Jul 19, 2017
  6. Feb 27, 2017
  7. Dec 21, 2016
  8. Oct 19, 2016
  9. Mar 22, 2016
    • Markus Armbruster's avatar
      include/qemu/osdep.h: Don't include qapi/error.h · da34e65c
      Markus Armbruster authored
      
      Commit 57cb38b3 included qapi/error.h into qemu/osdep.h to get the
      Error typedef.  Since then, we've moved to include qemu/osdep.h
      everywhere.  Its file comment explains: "To avoid getting into
      possible circular include dependencies, this file should not include
      any other QEMU headers, with the exceptions of config-host.h,
      compiler.h, os-posix.h and os-win32.h, all of which are doing a
      similar job to this file and are under similar constraints."
      qapi/error.h doesn't do a similar job, and it doesn't adhere to
      similar constraints: it includes qapi-types.h.  That's in excess of
      100KiB of crap most .c files don't actually need.
      
      Add the typedef to qemu/typedefs.h, and include that instead of
      qapi/error.h.  Include qapi/error.h in .c files that need it and don't
      get it now.  Include qapi-types.h in qom/object.h for uint16List.
      
      Update scripts/clean-includes accordingly.  Update it further to match
      reality: replace config.h by config-target.h, add sysemu/os-posix.h,
      sysemu/os-win32.h.  Update the list of includes in the qemu/osdep.h
      comment quoted above similarly.
      
      This reduces the number of objects depending on qapi/error.h from "all
      of them" to less than a third.  Unfortunately, the number depending on
      qapi-types.h shrinks only a little.  More work is needed for that one.
      
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      [Fix compilation without the spice devel packages. - Paolo]
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      da34e65c
  10. Mar 17, 2016
  11. Jan 29, 2016
  12. Dec 23, 2015
  13. Oct 22, 2015
    • Daniel P. Berrangé's avatar
      crypto: allow use of nettle/gcrypt to be selected explicitly · 91bfcdb0
      Daniel P. Berrangé authored
      
      Currently the choice of whether to use nettle or gcrypt is
      made based on what gnutls is linked to. There are times
      when it is desirable to be able to force build against a
      specific library. For example, if testing changes to QEMU's
      crypto code all 3 possible backends need to be checked
      regardless of what the local gnutls uses.
      
      It is also desirable to be able to enable nettle/gcrypt
      for cipher/hash algorithms, without enabling gnutls
      for TLS support.
      
      This gives two new configure flags, which allow the
      following possibilities
      
      Automatically determine nettle vs gcrypt from what
      gnutls links to (recommended to minimize number of
      crypto libraries linked to)
      
       ./configure
      
      Automatically determine nettle vs gcrypt based on
      which is installed
      
       ./configure --disable-gnutls
      
      Force use of nettle
      
       ./configure --enable-nettle
      
      Force use of gcrypt
      
       ./configure --enable-gcrypt
      
      Force use of built-in AES & crippled-DES
      
       ./configure --disable-nettle --disable-gcrypt
      
      Signed-off-by: default avatarDaniel P. Berrange <berrange@redhat.com>
      91bfcdb0
  14. Jul 08, 2015
Loading