Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 10 4月, 2019 3 次提交
  3. 09 4月, 2019 1 次提交
  5. 06 4月, 2019 1 次提交
  7. 05 4月, 2019 1 次提交
  9. 03 4月, 2019 12 次提交
  11. 28 3月, 2019 1 次提交
  13. 27 3月, 2019 1 次提交
  15. 20 3月, 2019 1 次提交
  17. 19 3月, 2019 1 次提交
    • D
      network: split setup of ipv4 and ipv6 top level chains · 686803a1
      由 Daniel P. Berrangé 提交于 
      During startup libvirtd creates top level chains for both ipv4
and ipv6 protocols. If this fails for any reason then startup
of virtual networks is blocked.

The default virtual network, however, only requires use of ipv4
and some servers have ipv6 disabled so it is expected that ipv6
chain creation will fail. There could equally be servers with
no ipv4, only ipv6.

This patch thus makes error reporting a little more fine grained
so that it works more sensibly when either ipv4 or ipv6 is
disabled on the server. Only the protocols that are actually
used by the virtual network have errors reported.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      686803a1
  19. 16 3月, 2019 1 次提交
    • E
      object: Add sanity check on correct parent class · 1c560052
      由 Eric Blake 提交于 
      Checking that the derived class is larger than the requested parent
class saves us from some obvious mistakes, but as written, it does not
catch all the cases; in particular, it is easy to forget to update a
VIR_CLASS_NEW when changing the 'parent' member from virObject to
virObjectLockabale, but where the size checks don't catch that.  Add a
parameter for one more layer of sanity checking.

It would be cool if we could get gcc to stringize typeof(parent) into
the string name of that type, so that we could confirm that the
precise parent class is in use rather than just a struct that happens
to have the same size as the parent class.  But sizeof checks are
better than nothing.

Note that I did NOT change the fact that we require derived classes to
be larger (as the difference in size makes it easy to tell classes
apart), which means that even if a derived class has no functionality
to add (but rather exists for compiler-enforced type-safety), it must
still include a dummy member.  But I did fix the wording of the error
message to match the code.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      1c560052
  21. 15 3月, 2019 2 次提交
    • E
      util: command: Introduce virCommandAddEnvXDG helper · 2d69af29
      由 Erik Skultety 提交于 
      Some modules/libraries within QEMU could make use of the XDG_ vars when
writing their data to the disk. Define the most common XDG variables
and point them to the specific driver's libDir, i.e.

XDG_CACHE_HOME -> /var/lib/libvirt/<driver>/.cache
XDG_DATA_HOME -> /var/lib/libvirt/<driver>/.local/share
XDG_CONFIG_HOME -> /var/lib/libvirt/<driver>/.config
Signed-off-by: NErik Skultety <eskultet@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      2d69af29
    • E
      virobject: Improve documentation · 632ac8f8
      由 Eric Blake 提交于 
      I had to inspect the code to learn whether a final virObjectUnref()
calls ALL dispose callbacks in child-to-parent order (akin to C++
destructors), or whether I manually had to call a parent-class dispose
when writing a child class dispose method.  The answer is the
former. (Thankfully, since VIR_FREE wipes out pointers for safety,
even if I had guessed wrong, I probably would not have tripped over a
double-free fault when the parent dispose ran for the second time).  I
also had to read the code to learn if a dispose method was even
mandatory (it is not, although getting NULL through VIR_CLASS_NEW
requires a macro).  While at it, the VIR_CLASS_NEW macro requires that
the virObject component at offset 0 be reached through the name
'parent', not 'object'.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>
      632ac8f8
  23. 14 3月, 2019 1 次提交
  25. 13 3月, 2019 1 次提交
  27. 12 3月, 2019 3 次提交
  29. 08 3月, 2019 5 次提交
  31. 07 3月, 2019 5 次提交