- 22 5月, 2012 1 次提交
-
-
由 Eric Blake 提交于
I'm tired of writing: bool sep = false; while (...) { if (sep) virBufferAddChar(buf, ','); sep = true; virBufferAdd(buf, str); } This makes it easier, allowing one to write: while (...) virBufferAsprintf(buf, "%s,", str); virBufferTrim(buf, ",", -1); to trim any remaining comma. * src/util/buf.h (virBufferTrim): Declare. * src/util/buf.c (virBufferTrim): New function. * tests/virbuftest.c (testBufTrim): Test it.
-
- 18 5月, 2012 2 次提交
-
-
由 Eric Blake 提交于
We were being lazy - virnetlink.c was getting uint32_t as a side-effect from glibc 2.14's <unistd.h>, but older glibc 2.11 does not provide uint32_t from <unistd.h>. In fact, POSIX states that <unistd.h> need only provide intptr_t, not all of <stdint.h>, so the bug really is ours. Reported by Jonathan Alescio. * src/util/virnetlink.h: Include <stdint.h>.
-
由 Hu Tao 提交于
This involves setting the cpuacct cgroup to a per-vcpu granularity, as well as summing the each vcpu accounting into a common array. Now that we are reading more than one cgroup file, we double-check that cpus weren't hot-plugged between reads to invalidate our summing. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 17 5月, 2012 1 次提交
-
-
由 Daniel P. Berrange 提交于
Allow the logging APIs to be called with a va_list for format args, instead of requiring var-args usage. * src/util/logging.h, src/util/logging.c: Add virLogVMessage
-
- 16 5月, 2012 4 次提交
-
-
由 Eric Blake 提交于
The use of readlink() in lxc_container.c is intentional; we don't want an absolute pathname there. * src/util/cgroup.h (VIR_CGROUP_SYSFS_MOUNT): Indent properly. * cfg.mk (exclude_file_name_regexp--sc_prohibit_readlink): Add exemption.
-
由 Daniel P. Berrange 提交于
Normal practice is for cgroups controllers to be mounted at /sys/fs/cgroup. When setting up a container, /sys is mounted with a new sysfs instance, thus we must re-mount all the cgroups controllers. The complexity is that we must mount them in the same layout as the host OS. ie if 'cpu' and 'cpuacct' were mounted at the same location in the host we must preserve this in the container. Also if any controllers are co-located we must setup symlinks from the individual controller name to the co-located mount-point Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Callers of virGetUser{Config,Runtime,Cache}Directory all append further path component. We should not be adding a trailing slash in the return path otherwise we get paths containing '//' Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Sometimes it is useful to see the callpath for log messages. This change enhances the log filter syntax so that stack traces can be show by setting '1:+NAME' instead of '1:NAME'. This results in output like: 2012-05-09 14:18:45.136+0000: 13314: debug : virInitialize:414 : register drivers /home/berrange/src/virt/libvirt/src/.libs/libvirt.so.0(virInitialize+0xd6)[0x7f89188ebe86] /home/berrange/src/virt/libvirt/tools/.libs/lt-virsh[0x431921] /lib64/libc.so.6(__libc_start_main+0xf5)[0x3a21e21735] /home/berrange/src/virt/libvirt/tools/.libs/lt-virsh[0x40a279] 2012-05-09 14:18:45.136+0000: 13314: debug : virRegisterDriver:775 : driver=0x7f8918d02760 name=Test /home/berrange/src/virt/libvirt/src/.libs/libvirt.so.0(virRegisterDriver+0x6b)[0x7f89188ec717] /home/berrange/src/virt/libvirt/src/.libs/libvirt.so.0(+0x11b3ad)[0x7f891891e3ad] /home/berrange/src/virt/libvirt/src/.libs/libvirt.so.0(virInitialize+0xf3)[0x7f89188ebea3] /home/berrange/src/virt/libvirt/tools/.libs/lt-virsh[0x431921] /lib64/libc.so.6(__libc_start_main+0xf5)[0x3a21e21735] /home/berrange/src/virt/libvirt/tools/.libs/lt-virsh[0x40a279] * docs/logging.html.in: Document new syntax * configure.ac: Check for execinfo.h * src/util/logging.c, src/util/logging.h: Add support for stack traces * tests/testutils.c: Adapt to API change Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 14 5月, 2012 1 次提交
-
-
由 William Jon McCann 提交于
As defined in: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html This offers a number of advantages: * Allows sharing a home directory between different machines, or sessions (eg. using NFS) * Cleanly separates cache, runtime (eg. sockets), or app data from user settings * Supports performing smart or selective migration of settings between different OS versions * Supports reseting settings without breaking things * Makes it possible to clear cache data to make room when the disk is filling up * Allows us to write a robust and efficient backup solution * Allows an admin flexibility to change where data and settings are stored * Dramatically reduces the complexity and incoherence of the system for administrators
-
- 09 5月, 2012 1 次提交
-
-
由 Jiri Denemark 提交于
Commit 64297313 added three direct references to nl_handle_* instead of using our aliases which hide differences between libnl-3 and libnl-1.
-
- 08 5月, 2012 4 次提交
-
-
由 Laine Stump 提交于
Until now, the nl_pid of the source address of every message sent by virNetlinkCommand has been set to the value of getpid(). Most of the time this doesn't matter, and in the one case where it does (communication with lldpad), it previously was the proper thing to do, because the netlink event service (which listens on a netlink socket for unsolicited messages from lldpad) coincidentally always happened to bind with a local nl_pid == getpid(). With the fix for: https://bugzilla.redhat.com/show_bug.cgi?id=816465 that particular nl_pid is now effectively a reserved value, so the netlink event service will always bind to something else (coincidentally "getpid() + (1 << 22)", but it really could be anything). The result is that communication between lldpad and libvirtd is broken (lldpad gets a "disconnected" error when it tries to send a directed message). The solution to this problem caused by a solution, is to query the netlink event service's nlhandle for its "local_port", and send that as the source nl_pid (but only when sending to lldpad, of course - in other cases we maintain the old behavior of sending getpid()). There are two cases where a message is being directed at lldpad - one in virNetDevLinkDump, and one in virNetDevVPortProfileOpSetLink. The case of virNetDevVPortProfileOpSetLink is simplest to explain - only if !nltarget_kernel, i.e. the message isn't targetted for the kernel, is the dst_pid set (by calling virNetDevVPortProfileGetLldpadPid()), so only in that case do we call virNetlinkEventServiceLocalPid() to set src_pid. For virNetDevLinkDump, it's a bit more complicated. The call to virNetDevVPortProfileGetLldpadPid() was effectively up one level (in virNetDevVPortProfileOpCommon), although obscured by an unnecessary passing of a function pointer. This patch removes the function pointer, and calls virNetDevVPortProfileGetLldpadPid() directly in virNetDevVPortProfileOpCommon - if it's doing this, it knows that it should also call virNetlinkEventServiceLocalPid() to set src_pid too; then it just passes src_pid and dst_pid down to virNetDevLinkDump. Since (src_pid == 0 && dst_pid == 0) implies that the kernel is the destination, there is no longer any need to send nltarget_kernel as an arg to virNetDevLinkDump, so it's been removed. The disparity between src_pid being int and dst_pid being uint32_t may be a bit disconcerting to some, but I didn't want to complicate virNetlinkEventServiceLocalPid() by having status returned separately from the value.
-
由 Laine Stump 提交于
This value will be needed to set the src_pid when sending netlink messages to lldpad. It is part of the solution to: https://bugzilla.redhat.com/show_bug.cgi?id=816465 Note that libnl's port generation algorithm guarantees that the nl_socket_get_local_port() will always be > 0 (since it is "getpid() + (n << 22>" where n is always < 1024), so it is okay to cast the uint32_t to int (thus allowing us to use -1 as an error sentinel).
-
由 Laine Stump 提交于
Until now, virNetlinkCommand has assumed that the nl_pid in the source address of outgoing netlink messages should always be the return value of getpid(). In most cases it actually doesn't matter, but in the case of communication with lldpad, lldpad saves this info and later uses it to send netlink messages back to libvirt. A recent patch to fix Bug 816465 changed the order of the universe such that the netlink event service socket is no longer bound with nl_pid == getpid(), so lldpad could no longer send unsolicited messages to libvirtd. Adding src_pid as an argument to virNetlinkCommand() is the first step in notifying lldpad of the proper address of the netlink event service socket.
-
由 Laine Stump 提交于
This is part of the solution to the problem detailed in: https://bugzilla.redhat.com/show_bug.cgi?id=816465 and further detailed in https://www.redhat.com/archives/libvir-list/2012-May/msg00202.htm A short explanation is included in the comments of the patch itself. Note that this patch by itself breaks communication between lldpad and libvirtd, so the other 3 patches in the series must be applied at the same time as this patch.
-
- 07 5月, 2012 1 次提交
-
-
由 Guannan Ren 提交于
usbFindDevice():get usb device according to idVendor, idProduct, bus, device it is the exact match of the four parameters usbFindDeviceByBus():get usb device according to bus, device it returns only one usb device same as usbFindDevice usbFindDeviceByVendor():get usb device according to idVendor,idProduct it probably returns multiple usb devices. usbDeviceSearch(): a helper function to do the actual search
-
- 05 5月, 2012 2 次提交
-
-
由 Laine Stump 提交于
These two functions are called from main() on all platforms, and always return success on platforms that don't support libnl. They still log an error message, though, which doesn't make sense - they should just be NOPs on those platforms. (Per a suggestion during review, I've turned the logs into debug messages rather than removing them completely).
-
由 Stefan Berger 提交于
Error: STRING_NULL: /libvirt/src/util/uuid.c:273: string_null_argument: Function "getDMISystemUUID" does not terminate string "*dmiuuid". /libvirt/src/util/uuid.c:241: string_null_argument: Function "saferead" fills array "*uuid" with a non-terminated string. /libvirt/src/util/util.c:101: string_null_argument: Function "read" fills array "*buf" with a non-terminated string. /libvirt/src/util/uuid.c:274: string_null: Passing unterminated string "dmiuuid" to a function expecting a null-terminated string. /libvirt/src/util/uuid.c:138: var_assign_parm: Assigning: "cur" = "uuidstr". They now point to the same thing. /libvirt/src/util/uuid.c:164: string_null_sink_loop: Searching for null termination in an unterminated array "cur".
-
- 04 5月, 2012 2 次提交
-
-
由 Osier Yang 提交于
-
由 Serge Hallyn 提交于
configure.ac: check for libnl-3 in addition to libnl-1 src/Makefile.am: link against libnl when needed src/util/virnetlink.c: support libnl3 api. To minimize impact on code flow, wrap the differences under the virNetlink* namespace. Unfortunately libnl3 moves netlink/msg.h to /usr/include/libnl3/netlink/msg.h, so the LIBNL_CFLAGS need to be added to a bunch of places where they weren't needed with libnl1. Signed-off-by: NSerge Hallyn <serge.hallyn@canonical.com> Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 03 5月, 2012 3 次提交
-
-
由 Dmitry Guryanov 提交于
Add function virJSONValueObjectKeysNumber, virJSONValueObjectGetKey and virJSONValueObjectGetValue, which allow you to iterate over all fields of json object: you can get number of fields and then get name and value, stored in field with that name by index. Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>
-
由 Marc-André Lureau 提交于
The code uses long long for pid_t now. It fails on mingw64 without this change.
-
由 Marc-André Lureau 提交于
Fix a few more places where pid_t is printed with wrong type
-
- 01 5月, 2012 1 次提交
-
-
由 Alex Jia 提交于
In fact, the 'tapfd' is always NULL, the function 'virNetDevTapCreate()' hasn't assign 'fd' to 'tapfd', when the function 'virNetDevSetMAC()' is failed then goto 'error' label, finally, the VIR_FORCE_CLOSE() will deref a NULL 'tapfd'. * util/virnetdevtap.c (virNetDevTapCreateInBridgePort): fix a NULL pointer derefing. * How to reproduce? $ cat > /tmp/net.xml <<EOF <network> <name>test</name> <forward mode='nat'/> <bridge name='br1' stp='off' delay='1' /> <mac address='00:00:00:00:00:00'/> <ip address='192.168.100.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.100.2' end='192.168.100.254' /> </dhcp> </ip> </network> EOF $ virsh net-define /tmp/net.xml $ virsh net-start test error: Failed to start network brTest error: End of file while reading data: Input/output error Signed-off-by: NAlex Jia <ajia@redhat.com>
-
- 30 4月, 2012 1 次提交
-
-
由 Jiri Denemark 提交于
When libvirtd is started, we create "libvirt/qemu" directories under hugetlbfs mount point. Only the "qemu" subdirectory is chowned to qemu user and "libvirt" remains owned by root. If umask was too restrictive when libvirtd started, qemu user may lose access to "qemu" subdirectory. Let's explicitly grant search permissions to "libvirt" directory for all users.
-
- 27 4月, 2012 2 次提交
-
-
由 Stefan Berger 提交于
Below patch fixes the following coverity findings Error: OVERRUN_STATIC: /libvirt/src/qemu/qemu_command.c:152: overrun-buffer-val: Overrunning static array "net->mac" of size 6 bytes by passing it as an argument to a function which indexes it at byte position 15. /libvirt/src/util/virnetdevmacvlan.c:948: access_dbuff_const: Calling "virNetDevMacVLanVPortProfileRegisterCallback" indexes array "macaddress" at byte position 15. /libvirt/src/util/virnetdevmacvlan.c:773: access_dbuff_const: Calling "memcpy" indexes array "macaddress" with index "16UL" at byte position 15. Error: OVERRUN_STATIC: /libvirt/src/qemu/qemu_migration.c:2744: overrun-buffer-val: Overrunning static array "net->mac" of size 6 bytes by passing it as an argument to a function which indexes it at byte position 15. /libvirt/src/util/virnetdevmacvlan.c:773: access_dbuff_const: Calling "memcpy" indexes array "macaddress" with index "16UL" at byte position 15. Error: OVERRUN_STATIC: /libvirt/src/qemu/qemu_driver.c:435: overrun-buffer-val: Overrunning static array "net->mac" of size 6 bytes by passing it as an argument to a function which indexes it at byte position 15. /libvirt/src/util/virnetdevmacvlan.c:1036: access_dbuff_const: Calling "virNetDevMacVLanVPortProfileRegisterCallback" indexes array "macaddress" at byte position 15. /libvirt/src/util/virnetdevmacvlan.c:773: access_dbuff_const: Calling "memcpy" indexes array "macaddress" with index "16UL" at byte position 15.
-
由 Laine Stump 提交于
Some of the error messages in this function should have been virReportSystemError (since they have an errno they want to log), but were mistakenly written as netlinkError, which expects a libvirt error code instead. The result was that when one of the errors was encountered, "No error message provided" would be printed instead of something meaningful (see https://bugzilla.redhat.com/show_bug.cgi?id=816465 for an example).
-
- 26 4月, 2012 1 次提交
-
-
由 Laine Stump 提交于
This patch resolves https://bugzilla.redhat.com/show_bug.cgi?id=815270 The function virNetDevMacVLanVPortProfileRegisterCallback() takes an arg "virtPortProfile", and was checking it for non-NULL before using it. However, the prototype for virNetDevMacVLanPortProfileRegisterCallback had marked that arg with ATTRIBUTE_NONNULL(). Contrary to what one may think, ATTRIBUTE_NONNULL() does not provide any guarantee that an arg marked as such really is always non-null; the only effect to the code generated by gcc, is that gcc *assumes* it is non-NULL; this results in, for example, the check for a non-NULL value being optimized out. (Unfortunately, this code removal only occurs when optimization is enabled, and I am in the habit of doing local builds with optimization off to ease debugging, so the bug didn't show up in my earlier local testing). In general, virPortProfile might always be NULL, so it shouldn't be marked as ATTRIBUTE_NONNULL. One other function prototype made this same error, so this patch fixes it as well.
-
- 25 4月, 2012 2 次提交
-
-
由 Stefan Berger 提交于
Add 2 new functions to the virSocketAddr 'class': - virSocketAddrEqual: tests whether two IP addresses and their ports are equal - virSocketaddSetIPv4Addr: set a virSocketAddr given a 32 bit int
-
由 Stefan Berger 提交于
Use embedded buffers for the MAC addresses and the VM's UUID.
-
- 24 4月, 2012 1 次提交
-
-
由 Stefan Berger 提交于
This patch improves the previously added virAtomicInt implementation by using gcc-builtins if possible. The needed builtins are available since GCC >= 4.1. At least the 4.0 docs don't mention them.
-
- 23 4月, 2012 1 次提交
-
-
由 Eric Blake 提交于
This patch introduces a new block job, useful for live storage migration using pre-copy streaming. Justification for including this under virDomainBlockRebase rather than adding a new command includes: 1) there are now two possible block jobs in qemu, with virDomainBlockRebase starting either type of command, and virDomainBlockJobInfo and virDomainBlockJobAbort working to end either type; 2) reusing this command allows distros to backport this feature to the libvirt 0.9.10 API without a .so bump. Note that a future patch may add a more powerful interface named virDomainBlockJobCopy, dedicated to just the block copy job, in order to expose even more options (such as setting an arbitrary format type for the destination without having to probe it from a pre-existing destination file); adding a new command for targetting just block copy would be similar to how we already have virDomainBlockPull for targetting just the block pull job. Using a live VM with the backing chain: base <- snap1 <- snap2 as the starting point, we have: - virDomainBlockRebase(dom, disk, "/path/to/copy", 0, VIR_DOMAIN_BLOCK_REBASE_COPY) creates /path/to/copy with the same format as snap2, with no backing file, so entire chain is copied and flattened - virDomainBlockRebase(dom, disk, "/path/to/copy", 0, VIR_DOMAIN_BLOCK_REBASE_COPY|VIR_DOMAIN_BLOCK_REBASE_COPY_RAW) creates /path/to/copy as a raw file, so entire chain is copied and flattened - virDomainBlockRebase(dom, disk, "/path/to/copy", 0, VIR_DOMAIN_BLOCK_REBASE_COPY|VIR_DOMAIN_BLOCK_REBASE_SHALLOW) creates /path/to/copy with the same format as snap2, but with snap1 as a backing file, so only snap2 is copied. - virDomainBlockRebase(dom, disk, "/path/to/copy", 0, VIR_DOMAIN_BLOCK_REBASE_COPY|VIR_DOMAIN_BLOCK_REBASE_REUSE_EXT) reuse existing /path/to/copy (must have empty contents, and format is probed[*] from the metadata), and copy the full chain - virDomainBlockRebase(dom, disk, "/path/to/copy", 0, VIR_DOMAIN_BLOCK_REBASE_COPY|VIR_DOMAIN_BLOCK_REBASE_REUSE_EXT| VIR_DOMAIN_BLOCK_REBASE_SHALLOW) reuse existing /path/to/copy (contents must be identical to snap1, and format is probed[*] from the metadata), and copy only the contents of snap2 - virDomainBlockRebase(dom, disk, "/path/to/copy", 0, VIR_DOMAIN_BLOCK_REBASE_COPY|VIR_DOMAIN_BLOCK_REBASE_REUSE_EXT| VIR_DOMAIN_BLOCK_REBASE_SHALLOW|VIR_DOMAIN_BLOCK_REBASE_COPY_RAW) reuse existing /path/to/copy (must be raw volume with contents identical to snap1), and copy only the contents of snap2 Less useful combinations: - virDomainBlockRebase(dom, disk, "/path/to/copy", 0, VIR_DOMAIN_BLOCK_REBASE_COPY|VIR_DOMAIN_BLOCK_REBASE_SHALLOW| VIR_DOMAIN_BLOCK_REBASE_COPY_RAW) fail if source is not raw, otherwise create /path/to/copy as raw and the single file is copied (no chain involved) - virDomainBlockRebase(dom, disk, "/path/to/copy", 0, VIR_DOMAIN_BLOCK_REBASE_COPY|VIR_DOMAIN_BLOCK_REBASE_REUSE_EXT| VIR_DOMAIN_BLOCK_REBASE_COPY_RAW) makes little sense: the destination must be raw but have no contents, meaning that it is an empty file, so there is nothing to reuse The other three flags are rejected without VIR_DOMAIN_BLOCK_COPY. [*] Note that probing an existing file for its format can be a security risk _if_ there is a possibility that the existing file is 'raw', in which case the guest can manipulate the file to appear like some other format. But, by virtue of the VIR_DOMAIN_BLOCK_REBASE_COPY_RAW flag, it is possible to avoid probing of raw files, at which point, probing of any remaining file type is no longer a security risk. It would be nice if we could issue an event when pivoting from phase 1 to phase 2, but qemu hasn't implemented that, and we would have to poll in order to synthesize it ourselves. Meanwhile, qemu will give us a distinct job info and completion event when we either cancel or pivot to end the job. Pivoting is accomplished via the new: virDomainBlockJobAbort(dom, disk, VIR_DOMAIN_BLOCK_JOB_ABORT_PIVOT) Management applications can pre-create the copy with a relative backing file name, and use the VIR_DOMAIN_BLOCK_REBASE_REUSE_EXT flag to have qemu reuse the metadata; if the management application also copies the backing files to a new location, this can be used to perform live storage migration of an entire backing chain. * include/libvirt/libvirt.h.in (VIR_DOMAIN_BLOCK_JOB_TYPE_COPY): New block job type. (virDomainBlockJobAbortFlags, virDomainBlockRebaseFlags): New enums. * src/libvirt.c (virDomainBlockRebase): Document the new flags, and implement general restrictions on flag combinations. (virDomainBlockJobAbort): Document the new flag. (virDomainSaveFlags, virDomainSnapshotCreateXML) (virDomainRevertToSnapshot, virDomainDetachDeviceFlags): Document restrictions. * include/libvirt/virterror.h (VIR_ERR_BLOCK_COPY_ACTIVE): New error. * src/util/virterror.c (virErrorMsg): Define it.
-
- 22 4月, 2012 1 次提交
-
-
由 Matthias Bolte 提交于
virThreadSelf tries to access the virThreadPtr stored in TLS for the current thread via TlsGetValue. When virThreadSelf is called on a thread that was not created via virThreadCreate (e.g. the main thread) then TlsGetValue returns NULL as TlsAlloc initializes TLS slots to NULL. virThreadSelf can be called on the main thread via this call chain from virsh vshDeinit virEventAddTimeout virEventPollAddTimeout virEventPollInterruptLocked virThreadIsSelf triggering a segfault as virThreadSelf unconditionally dereferences the return value of TlsGetValue. Fix this by making virThreadSelf check the TLS slot value for NULL and setting the given virThreadPtr accordingly. Reported by Marcel Müller.
-
- 20 4月, 2012 3 次提交
-
-
由 Eric Blake 提交于
Ensure we don't introduce any more lousy integer parsing in new code, while avoiding a scrub-down of existing legacy code. Note that we also need to enable sc_prohibit_atoi_atof (see cfg.mk local-checks-to-skip) before we are bulletproof, but that also entails scrubbing I'm not ready to do at the moment. * src/util/util.c (virStrToLong_i, virStrToLong_ui) (virStrToLong_l, virStrToLong_ul, virStrToLong_ll) (virStrToLong_ull, virStrToDouble): Mark exemptions. * src/util/virmacaddr.c (virMacAddrParse): Likewise. * cfg.mk (sc_prohibit_strtol): New syntax check. (exclude_file_name_regexp--sc_prohibit_strtol): Ignore files that I'm not willing to fix yet. (local-checks-to-skip): Re-enable sc_prohibit_atoi_atof.
-
由 Eric Blake 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=617711 reported that even with my recent patched to allow <memory unit='G'>1</memory>, people can still get away with trying <memory>1G</memory> and silently get <memory unit='KiB'>1</memory> instead. While virt-xml-validate catches the error, our C parser did not. Not to mention that it's always fun to fix bugs while reducing lines of code. :) * src/conf/domain_conf.c (virDomainParseMemory): Check for parse error. (virDomainDefParseXML): Avoid strtoll. * src/conf/storage_conf.c (virStorageDefParsePerms): Likewise. * src/util/xml.c (virXPathLongBase, virXPathULongBase) (virXPathULongLong, virXPathLongLong): Likewise.
-
由 Daniel P. Berrange 提交于
DBus connection. The HAL device code further requires that the DBus connection is integrated with the event loop and provides such glue logic itself. The forthcoming FirewallD integration also requires a dbus connection with event loop integration. Thus we need to pull the current event loop glue out of the HAL driver. Thus we create src/util/virdbus.{c,h} files. This contains just one method virDBusGetSystemBus() which obtains a handle to the single shared system bus instance, with event glue automagically setup.
-
- 19 4月, 2012 3 次提交
-
-
由 Stefan Berger 提交于
For threading support, add atomic add and sub operations working on integers. Base this on locking support provided by virMutex.
-
由 Stefan Berger 提交于
Implement function to remove all entries of a hash table.
-
由 Eric Blake 提交于
The sequence: long long val; if ((long long) val != val) is dead code. * src/util/util.c (virStrToLong_ll, virStrToLong_ull): Remove useless cast.
-
- 18 4月, 2012 1 次提交
-
-
由 D. Herrendoerfer 提交于
Currently upon a migration a callback is created when a 802.1qbg link is set to PREASSOCIATE, this should not happen because this is a no-op on most switches, and does not lead to an ASSOCIATE state. This patch only creates callbacks when CREATE or RESTORE is requested. Migration and libvirtd restart scenarios are already handled elsewhere. Signed-off-by: ND. Herrendoerfer <d.herrendoerfer@herrendoerfer.name>
-
- 14 4月, 2012 1 次提交
-
-
由 Philipp Hahn 提交于
The linux-2.6.32 kernel header does not yet define IFLA_VF_MAX and others, which breaks compiling a new libvirt on old systems like Debian Squeeze. (I also have to add --without-macvtap --disable-werror --without-virtualport to ./configure to get it to compile.) Signed-off-by: NPhilipp Hahn <hahn@univention.de>
-