Probing capabilities takes 200-300ms per binary and we have as many as 26 binaries. This noticably slows down libvirtd startup. It does not look like performance of probing QEMU can be improved, so this series introduces caching of the capabilities information. So the first time libvirtd starts it'll be slow, but thereafter it is fast. The cache is invalidated any time the QEMU binary timestamp changes or the libvirtd binary or driver module timestamp changes. Daniel P. Berrange (4): Add helper APIs for generating cryptographic hashes Convert lock driver plugins to use new crypto APIs Cache result of QEMU capabilities extraction Refresh qemu capabilities if libvirtd binary changes .gitignore | 1 + daemon/libvirtd.c | 2 + include/libvirt/virterror.h | 1 + po/POTFILES.in | 1 + src/Makefile.am | 1 + src/driver.c | 2 + src/libvirt_private.syms | 6 + src/locking/lock_driver_lockd.c | 32 +-- src/locking/lock_driver_sanlock.c | 42 +--- src/qemu/qemu_capabilities.c | 418 +++++++++++++++++++++++++++++++++++++- src/qemu/qemu_capabilities.h | 2 + src/qemu/qemu_driver.c | 1 + src/util/vircrypto.c | 80 ++++++++ src/util/vircrypto.h | 40 ++++ src/util/virerror.c | 1 + src/util/virutil.c | 23 +++ src/util/virutil.h | 4 + tests/Makefile.am | 5 + tests/vircryptotest.c | 90 ++++++++ 19 files changed, 682 insertions(+), 70 deletions(-) create mode 100644 src/util/vircrypto.c create mode 100644 src/util/vircrypto.h create mode 100644 tests/vircryptotest.c -- 1.8.5.3 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list