1. 23 10月, 2019 2 次提交
  2. 18 10月, 2019 2 次提交
  3. 14 10月, 2019 1 次提交
    • D
      build: link to glib library · cfbe9f12
      Daniel P. Berrangé 提交于
      Add the main glib.h to internal.h so that all common code can use it.
      
      Historically glib allowed applications to register an alternative
      memory allocator, so mixing g_malloc/g_free with malloc/free was not
      safe.
      
      This was feature was dropped in 2.46.0 with:
      
            commit 3be6ed60aa58095691bd697344765e715a327fc1
            Author: Alexander Larsson <alexl@redhat.com>
            Date:   Sat Jun 27 18:38:42 2015 +0200
      
              Deprecate and drop support for memory vtables
      
      Applications are still encourged to match g_malloc/g_free, but it is no
      longer a mandatory requirement for correctness, just stylistic. This is
      explicitly clarified in
      
          commit 1f24b36607bf708f037396014b2cdbc08d67b275
          Author: Daniel P. Berrangé <berrange@redhat.com>
          Date:   Thu Sep 5 14:37:54 2019 +0100
      
              gmem: clarify that g_malloc always uses the system allocator
      
      Applications can still use custom allocators in general, but they must
      do this by linking to a library that replaces the core malloc/free
      implemenentation entirely, instead of via a glib specific call.
      
      This means that libvirt does not need to be concerned about use of
      g_malloc/g_free causing an ABI change in the public libary, and can
      avoid memory copying when talking to external libraries.
      
      This patch probes for glib, which provides the foundation layer with
      a collection of data structures, helper APIs, and platform portability
      logic.
      
      Later patches will introduce linkage to gobject which provides the
      object type system, built on glib, and gio which providing objects
      for various interesting tasks, most notably including DBus client
      and server support and portable sockets APIs, but much more too.
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      cfbe9f12
  4. 01 10月, 2019 1 次提交
  5. 04 9月, 2019 1 次提交
  6. 27 8月, 2019 2 次提交
  7. 23 8月, 2019 1 次提交
    • R
      build: Use flat namespace for libvirt on macOS · 740f181c
      Roman Bolshakov 提交于
      >From ld(1):
      
        By default all references resolved to a dynamic library record the
        library to which they were resolved. At runtime, dyld uses that
        information to directly resolve symbols. The alternative is to use the
        -flat_namespace option.  With flat namespace, the library is not
        recorded.  At runtime, dyld will search each dynamic library in load
        order when resolving symbols. This is slower, but more like how other
        operating systems resolve symbols.
      
      That fixes the set of tests that preload a mock library to replace
      library symbols:
        qemublocktest
        qemumonitorjsontest
        viriscsitest
        virmacmaptest
        virnetserverclienttest
      Signed-off-by: NRoman Bolshakov <r.bolshakov@yadro.com>
      740f181c
  8. 20 8月, 2019 1 次提交
  9. 14 8月, 2019 1 次提交
  10. 09 8月, 2019 5 次提交
  11. 07 8月, 2019 2 次提交
  12. 27 7月, 2019 1 次提交
    • E
      backup: Introduce virDomainCheckpoint APIs · 0d44788f
      Eric Blake 提交于
      Introduce a bunch of new public APIs related to backup checkpoints.
      Checkpoints are modeled heavily after virDomainSnapshotPtr (both
      represent a point in time of the guest), although a snapshot exists
      with the intent of rolling back to that state, while a checkpoint
      exists to make it possible to create an incremental backup at a later
      time.  We may have a future hypervisor that can completely manage
      checkpoints without libvirt metadata, but the first two planned
      hypervisors (qemu and test) both always use libvirt for tracking
      metadata relations between checkpoints, so for now, I've deferred
      the counterpart of virDomainSnapshotHasMetadata for a separate
      API addition at a later date if there is ever a need for it.
      
      Note that until we allow snapshots and checkpoints to exist
      simultaneously on the same domain (although the actual prevention of
      this will be in a separate patch for the sake of an easier revert down
      the road), that it is not possible to branch out to create more than
      one checkpoint child to a given parent, although it may become
      possible later when we revert to a snapshot that coincides with a
      checkpoint.  This also means that for now, the decision of which
      checkpoint becomes the parent of a newly created one is the only
      checkpoint with no child (so while there are APIs for dealing with a
      current snapshot, we do not need those for checkpoints).  We may end
      up exposing a notion of a current checkpoint later, but it's easier to
      add stuff when proven needed than to blindly support it now and wish
      we hadn't exposed it.
      
      The following map shows the API relations to snapshots, with new APIs
      on the right:
      
      Operate on a domain object to create/redefine a child:
      virDomainSnapshotCreateXML          virDomainCheckpointCreateXML
      
      Operate on a child object for lifetime management:
      virDomainSnapshotDelete             virDomainCheckpointDelete
      virDomainSnapshotFree               virDomainCheckpointFree
      virDomainSnapshotRef                virDomainCheckpointRef
      
      Operate on a child object to learn more about it:
      virDomainSnapshotGetXMLDesc         virDomainCheckpointGetXMLDesc
      virDomainSnapshotGetConnect         virDomainCheckpointGetConnect
      virDomainSnapshotGetDomain          virDomainCheckpointGetDomain
      virDomainSnapshotGetName            virDomainCheckpiontGetName
      virDomainSnapshotGetParent          virDomainCheckpiontGetParent
      virDomainSnapshotHasMetadata        (deferred for later)
      virDomainSnapshotIsCurrent          (no counterpart, see note above)
      
      Operate on a domain object to list all children:
      virDomainSnapshotNum                (no counterparts, these are the old
      virDomainSnapshotListNames           racy interfaces)
      virDomainSnapshotListAllSnapshots   virDomainListAllCheckpoints
      
      Operate on a child object to list descendents:
      virDomainSnapshotNumChildren        (no counterparts, these are the old
      virDomainSnapshotListChildrenNames   racy interfaces)
      virDomainSnapshotListAllChildren    virDomainCheckpointListAllChildren
      
      Operate on a domain to locate a particular child:
      virDomainSnapshotLookupByName       virDomainCheckpointLookupByName
      virDomainSnapshotCurrent            (no counterpart, see note above)
      virDomainHasCurrentSnapshot         (no counterpart, old racy interface)
      
      Operate on a snapshot to roll back to earlier state:
      virDomainSnapshotRevert             (no counterpart, instead checkpoints
                                           are used in incremental backups via
      				     XML to virDomainBackupBegin)
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      0d44788f
  13. 17 5月, 2019 1 次提交
    • D
      src: don't statically link code that's already in libvirt.so · e5df4ede
      Daniel P. Berrangé 提交于
      Various binaries are statically linking to libvirt_util.la and
      other intermediate libraries we build. These intermediate libs
      all get built into the main libvirt.so shared library eventually,
      so we can dynamically link to that instead and reduce the on disk
      footprint.
      
      In libvirt-daemon RPM:
      
                  virtlockd: 1.6 MB -> 153 KB
                   virtlogd: 1.6 MB -> 157 KB
           libvirt_iohelper: 937 KB -> 23 KB
      
      In libvirt-daemon-driver-network RPM:
      
       libvirt_leaseshelper: 940 KB -> 26 KB
      
      In libvirt-daemon-driver-storage-core RPM:
      
         libvirt_parthelper: 926 KB -> 21 KB
      
      IOW, about 5.6 MB total space saving in a build done on Fedora 30
      x86_64 architecture.
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      e5df4ede
  14. 11 4月, 2019 1 次提交
    • D
      build-aux: ensure all scripts are included in EXTRA_DIST · d5cbf85f
      Daniel P. Berrangé 提交于
      Few of the scripts in build-aux are included in EXTRA_DIST. This is not
      a serious problem since they are primarily tools intended for developers
      upstream, and downstream builds won't need them. Having them missing,
      however, complicates downstream patching because it means patches that
      are auto-exported from git will fail to apply if they include a change
      to a file in build-aux/.  By bundling all these scripts in the dist we
      make patching more straightforward.
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      d5cbf85f
  15. 10 4月, 2019 2 次提交
  16. 16 3月, 2019 2 次提交
  17. 15 3月, 2019 1 次提交
  18. 14 3月, 2019 2 次提交
  19. 16 1月, 2019 1 次提交
  20. 10 1月, 2019 3 次提交
  21. 08 1月, 2019 2 次提交
  22. 18 12月, 2018 1 次提交
  23. 05 10月, 2018 1 次提交
    • P
      util: introduce cgroup v2 files · b4ddf5ae
      Pavel Hrdina 提交于
      Place cgroup v2 backend type before cgroup v1 to make it obvious
      that cgroup v2 is preferred implementation.
      
      Following patches will introduce support for hybrid configuration
      which will allow us to use both at the same time, but we should
      prefer cgroup v2 regardless.
      Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      b4ddf5ae
  24. 25 9月, 2018 2 次提交
  25. 28 8月, 2018 1 次提交