Quite a few of the tests have a need to mock the stat() / lstat() functions and they are taking somewhat different & inconsistent approaches none of which are actually fully correct. This is shown by fact that 'make check' fails on 32-bit hosts. Investigation revealed that the code was calling into the native C library impl, not getting intercepted by our mocks. The POSIX stat() function might resolve to any number of different symbols in the C library. The may be an additional stat64() function exposed by the headers too. On 64-bit hosts the stat & stat64 functions are identical, always refering to the 64-bit ABI. On 32-bit hosts they refer to the 32-bit & 64-bit ABIs respectively. Libvirt uses _FILE_OFFSET_BITS=64 on 32-bit hosts, which causes the C library to transparently rewrite stat() calls to be stat64() calls. Libvirt will never see the 32-bit ABI from the traditional stat() call. We cannot assume this rewriting is done using a macro. It might be, but on GLibC it is done with a magic __asm__ statement to apply the rewrite at link time instead of at preprocessing. In GLibC there may be two additional functions exposed by the headers, __xstat() and __xstat64(). When these exist, stat() and stat64() are transparently rewritten to call __xstat() and __xstat64() respectively. The former symbols will not actally exist in the library at all, only the header. The leading "__" indicates the symbols are a private impl detail of the C library that applications should not care about. Unfortunately, because we are trying to mock replace the C library, we need to know about this internal impl detail. With all this in mind the list of functions we have to mock will depend on several factors - If _FILE_OFFSET_BITS is set, then we are on a 32-bit host, and we only need to mock stat64 and __xstat64. The other stat / __xstat functions exist, but we'll never call them so they can be ignored for mocking. - If _FILE_OFFSET_BITS is not set, then we are on a 64-bit host and we should mock stat, stat64, __xstat & __xstat64. Either may be called by app code. - If __xstat & __xstat64 exist, then stat & stat64 will not exist as symbols in the library, so the latter should not be mocked. The same all applies to lstat() These rules are complex enough that we don't want to duplicate them across every mock file, so this centralizes all the logic in a helper file virmockstathelper.c that should be #included when needed. The code merely need to provide a filename rewriting callback called virMockStatRedirect(). Optionally VIR_MOCK_STAT_HOOK can be defined as a macro if further processing is needed inline. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Libvirt API for virtualization
Libvirt provides a portable, long term stable C API for managing the virtualization technologies provided by many operating systems. It includes support for QEMU, KVM, Xen, LXC, bhyve, Virtuozzo, VMware vCenter and ESX, VMware Desktop, Hyper-V, VirtualBox and the POWER Hypervisor.
For some of these hypervisors, it provides a stateful management daemon which runs on the virtualization host allowing access to the API both by non-privileged local users and remote users.
Layered packages provide bindings of the libvirt C API into other languages including Python, Perl, PHP, Go, Java, OCaml, as well as mappings into object systems such as GObject, CIM and SNMP.
Further information about the libvirt project can be found on the website:
License
The libvirt C API is distributed under the terms of GNU Lesser General
Public License, version 2.1 (or later). Some parts of the code that are
not part of the C library may have the more restrictive GNU General
Public License, version 2.1 (or later). See the files COPYING.LESSER
and COPYING
for full license terms & conditions.
Installation
Libvirt uses the GNU Autotools build system, so in general can be built and installed with the usual commands. For example, to build in a manner that is suitable for installing as root, use:
$ ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
$ make
$ sudo make install
While to build & install as an unprivileged user
$ ./configure --prefix=$HOME/usr
$ make
$ make install
The libvirt code relies on a large number of 3rd party libraries. These will
be detected during execution of the configure
script and a summary printed
which lists any missing (optional) dependencies.
Contributing
The libvirt project welcomes contributions in many ways. For most components the best way to contribute is to send patches to the primary development mailing list. Further guidance on this can be found on the website:
https://libvirt.org/contribute.html
Contact
The libvirt project has two primary mailing lists:
- libvirt-users@redhat.com (for user discussions)
- libvir-list@redhat.com (for development only)
Further details on contacting the project are available on the website: