1. 26 4月, 2013 2 次提交
    • E
      build: avoid unsafe functions in libgen.h · 1fbf1905
      Eric Blake 提交于
      POSIX says that both basename() and dirname() may return static
      storage (aka they need not be thread-safe); and that they may but
      not must modify their input argument.  Furthermore, <libgen.h>
      is not available on all platforms.  For these reasons, you should
      never use these functions in a multi-threaded library.
      
      Gnulib instead recommends a way to avoid the portability nightmare:
      gnulib's "dirname.h" provides useful thread-safe counterparts.  The
      obvious dir_name() and base_name() are GPL (because they malloc(),
      but call exit() on failure) so we can't use them; but the LGPL
      variants mdir_name() (malloc's or returns NULL) and last_component
      (always points into the incoming string without modifying it,
      differing from basename semantics only on corner cases like the
      empty string that we shouldn't be hitting in the first place) are
      already in use in libvirt.  This finishes the swap over to the safe
      functions.
      
      * cfg.mk (sc_prohibit_libgen): New rule.
      * src/util/vircgroup.c: Fix offenders.
      * src/parallels/parallels_storage.c (parallelsPoolAddByDomain):
      Likewise.
      * src/parallels/parallels_network.c (parallelsGetBridgedNetInfo):
      Likewise.
      * src/node_device/node_device_udev.c (udevProcessSCSIHost)
      (udevProcessSCSIDevice): Likewise.
      * src/storage/storage_backend_disk.c
      (virStorageBackendDiskDeleteVol): Likewise.
      * src/util/virpci.c (virPCIGetDeviceAddressFromSysfsLink):
      Likewise.
      * src/util/virstoragefile.h (_virStorageFileMetadata): Avoid false
      positive.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      1fbf1905
    • E
      qemu: fix build error with older platforms · b121584f
      Eric Blake 提交于
      Jim Fehlig reported on IRC that older gcc/glibc triggers this warning:
      
      cc1: warnings being treated as errors
      qemu/qemu_domain.c: In function 'qemuDomainDefFormatBuf':
      qemu/qemu_domain.c:1297: error: declaration of 'remove' shadows a global declaration [-Wshadow]
      /usr/include/stdio.h:157: error: shadowed declaration is here [-Wshadow]
      make[3]: *** [libvirt_driver_qemu_impl_la-qemu_domain.lo] Error 1
      
      Fix it like we have done in the past (such as commit 2e6322a7).
      
      * src/qemu/qemu_domain.c (qemuDomainDefFormatBuf): Avoid shadowing
      a function name.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      b121584f
  2. 25 4月, 2013 17 次提交
  3. 24 4月, 2013 19 次提交
  4. 23 4月, 2013 2 次提交
    • D
      Switch to a more extensible annotation system for RPC protocols · a98541bf
      Daniel P. Berrange 提交于
      Currently the RPC protocol files can contain annotations after
      the protocol enum eg
      
         REMOTE_PROC_DOMAIN_SNAPSHOT_LIST_CHILDREN_NAMES = 247, /* autogen autogen priority:high */
      
      This is not very extensible as the number of annotations grows.
      Change it to use
      
          /**
           * @generate: both
           * @priority: high
           */
         REMOTE_PROC_DOMAIN_SNAPSHOT_LIST_CHILDREN_NAMES = 247,
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      a98541bf
    • P
      qemu: Fix setting of memory tunables · fa006c4f
      Peter Krempa 提交于
      Refactoring done in 19c6ad9a didn't
      correctly take into account the order cgroup limit modification needs to
      be done in. This resulted into errors when decreasing the limits.
      
      The operations need to take place in this order:
      
      decrease hard limit
      change swap hard limit
      
      or
      
      change swap hard limit
      increase hard limit
      
      This patch also fixes the check if the hard_limit is less than
      swap_hard_limit to print better error messages. For this purpose I
      introduced a helper function virCompareLimitUlong to compare limit
      values where value of 0 is equal to unlimited. Additionally the check is
      now applied also when the user does not provide all of the tunables
      through the API and in that case the currently set values are used.
      
      This patch resolves:
      https://bugzilla.redhat.com/show_bug.cgi?id=950478
      fa006c4f