- 03 6月, 2020 2 次提交
-
-
由 Daniel P. Berrangé 提交于
To avoid bugs with mixing of g_object_(ref|unref) vs virObject(Ref|Unref), we want every virObject to be a GObject. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
To prepare for a conversion to GObject, we need virObjectUnref to have the same API design as g_object_unref, which means it needs to be void. A few places do actually care about the return value though, and in these cases a thread local flag is used to determine if the dispose method was invoked. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 02 2月, 2020 4 次提交
-
-
由 Michal Privoznik 提交于
Now, that every use of virAtomic was replaced with its g_atomic equivalent, let's remove the module. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 22 11月, 2019 1 次提交
-
-
由 Daniel P. Berrangé 提交于
This previous commit introduced a simpler free callback for hash data with only 1 arg, the value to free: commit 49288fac Author: Peter Krempa <pkrempa@redhat.com> Date: Wed Oct 9 15:26:37 2019 +0200 util: hash: Add possibility to use simpler data free function in virHash It missed two functions in the hash table code which need to call the alternate data free function, virHashRemoveEntry and virHashRemoveSet. After the previous patch though, there is no code that makes functional use of the 2nd key arg in the data free function. There is merely one log message that can be dropped. We can thus purge the current virHashDataFree callback entirely, and rename virHashDataFreeSimple to replace it. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 21 10月, 2019 1 次提交
-
-
由 Ján Tomko 提交于
Replace all occurrences of if (VIR_STRDUP(a, b) < 0) /* effectively dead code */ with: a = g_strdup(b); Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 16 10月, 2019 1 次提交
-
-
由 Ján Tomko 提交于
Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 15 10月, 2019 1 次提交
-
-
由 Ján Tomko 提交于
Use G_GNUC_UNUSED from GLib instead of ATTRIBUTE_UNUSED. Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 16 3月, 2019 1 次提交
-
-
由 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>
-
- 15 3月, 2019 1 次提交
-
-
由 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>
-
- 04 3月, 2019 1 次提交
-
-
由 Peter Krempa 提交于
The helper function is used by the VIR_AUTOUNREF macro. Prior art is to clear the pointer even if the variable goes out of scope. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 18 2月, 2019 1 次提交
-
-
由 Peter Krempa 提交于
Add helper for utilizing __attribute__(cleanup())) for unref-ing instances of sublasses of virObject. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
- 24 9月, 2018 1 次提交
-
-
由 Shi Lei 提交于
This patch just fixes misaligned arguments and misaligned conditions of src/util/*.c. Signed-off-by: NShi Lei <shi_lei@massclouds.com>
-
- 16 5月, 2018 1 次提交
-
-
由 Daniel P. Berrangé 提交于
It only accepts a virObjecLockable, not a virObjecRWLockable Reviewed-by: NJiri Denemark <jdenemar@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 18 4月, 2018 1 次提交
-
-
由 Michal Privoznik 提交于
So far we are repeating the following lines over and over: if (!(virSomeObjectClass = virClassNew(virClassForObject(), "virSomeObject", sizeof(virSomeObject), virSomeObjectDispose))) return -1; While this works, it is impossible to do some checking. Firstly, the class name (the 2nd argument) doesn't match the name in the code in all cases (the 3rd argument). Secondly, the current style is needlessly verbose. This commit turns example into following: if (!(VIR_CLASS_NEW(virSomeObject, virClassForObject))) return -1; Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 03 11月, 2017 1 次提交
-
-
由 Andrea Bolognani 提交于
Right-aligning backslashes when defining macros or using complex commands in Makefiles looks cute, but as soon as any changes is required to the code you end up with either distractingly broken alignment or unnecessarily big diffs where most of the changes are just pushing all backslashes a few characters to one side. Generated using $ git grep -El '[[:blank:]][[:blank:]]\\$' | \ grep -E '*\.([chx]|am|mk)$$' | \ while read f; do \ sed -Ei 's/[[:blank:]]*[[:blank:]]\\$/ \\/g' "$f"; \ done Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
-
- 15 8月, 2017 8 次提交
-
-
由 John Ferlan 提交于
Rather than assuming that what's passed to virObject{Ref|Unref} would be a virObjectPtr as long as it's not NULL, let's do the similar checks virObjectIsClass in order to prevent a possible increment or decrement to some field at the obj->u.s.refs offset. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
The virObjectIsClass API has only ever checked object validity based on if the @obj is not NULL and it was derived from some class. While this has worked well in general, there is one additional check that could be made prior to calling virClassIsDerivedFrom which loops through the classes checking the magic number against the klass expected magic number. If by chance a non virObject is passed, rather than assuming the void * @obj is a _virObject and thus offsetting to obj->klass, obj->magic, and obj->parent, let's check that the void * @obj has at least the "base part" of the magic number in the right place and generate a more specific VIR_WARN message if not. There are many consumers to virObjectIsClass, include the locking primitives virObject{Lock|Unlock}, virObjectRWLock{Read|Write}, and virObjectRWUnlock. For those callers, the locking call will not fail, but it also will not attempt a virMutex* call which will "most likely" fail since the &obj->lock is used. In order to avoid some possible future wrap on the 0xCAFExxxx value, add a check during initialization that some new class won't cause the wrap. Should be good for a few years at least! It is still left up to the caller to handle the failed API calls just as it would be if it passed a NULL opaque pointer anyobj.
-
由 John Ferlan 提交于
If virObjectIsClass fails "internally" to virobject.c, create a macro to generate the VIR_WARN describing what the problem is. Also improve the checks and message a bit to indicate which was the failure - whether the obj was NULL or just not the right class Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Rather than overload virObjectUnlock as commit id '77f4593b' has done, create a separate virObjectRWUnlock API that will force the consumers to make the proper decision regarding unlocking the RWLock's. Similar to the RWLockRead and RWLockWrite, use the virObjectGetRWLockableObj helper. This restores the virObjectUnlock code to using the virObjectGetLockableObj. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Introduce a helper to handle the error path more cleanly. The same as virObjectGetLockableObj in order to essentially follow the original logic of commit 'b545f65d' to ensure that the input argument at least has some validity before using. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Now that virObjectRWLockWrite exists to handle the virObjectRWLockable objects, let's restore virObjectLock to only handle virObjectLockable class locks. There still exists the possibility that the input @anyobj isn't a valid object and the resource isn't truly locked, but that also exists before commit id '77f4593b'. This also restores some logic that commit id '77f4593b' removed with respect to a common code path that commit id '10c2bb2b' had introduced as virObjectGetLockableObj. This code path merely does the same checks as the original virObjectLock commit 'b545f65d', but in callable/reusable helper to ensure the @obj at least has some validity before using. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Instead of making virObjectLock be the entry point for two different types of locks, let's create a virObjectRWLockWrite API which will only handle the virObjectRWLockableClass objects. Use the new virObjectRWLockWrite for the virdomainobjlist code in order to handle the Add, Remove, Rename, and Load operations that need to be very synchronous. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Since the class it represents is based on virObjectRWLockableClass and in order to make sure we differentiate just in case anyone somehow believes they could use virObjectLockRead for a virObjectLockableClass, let's rename the API to use the RW in the name. Besides the RW locks refer to pthread_rwlock_{init|rdlock|wrlock|unlock|destroy} while the other locks refer to pthread_mutex_{init|lock|unlock|destroy}. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 25 7月, 2017 1 次提交
-
-
由 Michal Privoznik 提交于
This reverts commit 328bd244. As it turns out, this is not portable and very Linux & glibc specific. Worse, this may lead to not starving writers on Linux but everywhere else. Revert this and if the starvation occurs resolve it. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 24 7月, 2017 1 次提交
-
-
由 Michal Privoznik 提交于
Up until now we only had virObjectLockable which uses mutexes for mutually excluding each other in critical section. Well, this is not enough. Future work will require RW locks so we might as well have virObjectRWLockable which is introduced here. Moreover, polymorphism is introduced to our code for the first time. Yay! More specifically, virObjectLock will grab a write lock, virObjectLockRead will grab a read lock then (what a surprise right?). This has great advantage that an object can be made derived from virObjectRWLockable in a single line and still continue functioning properly (mutexes can be viewed as grabbing write locks only). Then just those critical sections that can grab a read lock need fixing. Therefore the resulting change is going to be way smaller. In order to avoid writer starvation, the object initializes RW lock that prefers writers. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
- 22 6月, 2017 2 次提交
-
-
由 John Ferlan 提交于
Split out the object fetch in virObject{Lock|Unlock} into a helper Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Alter to use more recent formatting guidelines Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 11 5月, 2015 1 次提交
-
-
由 Peter Krempa 提交于
Extend it to a universal helper used for clearing lists of any objects. Note that the argument type is specifically void * to allow implicit typecasting. Additionally add a helper that works on non-NULL terminated arrays once we know the length.
-
- 28 11月, 2014 1 次提交
-
-
由 Jiri Denemark 提交于
virReportSystemError is reserved for reporting system errors, calling it with VIR_ERR_* error codes produces error messages that do not make any sense, such as internal error: guest failed to start: Kernel doesn't support user namespace: Link has been severed We should prohibit wrong usage with a syntax-check rule. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 07 4月, 2014 1 次提交
-
-
由 Eric Blake 提交于
I almost wrote a hash value free function that just called VIR_FREE, then realized I couldn't be the first person to do that. Sure enough, it was worth factoring into a common helper routine. * src/util/virhash.h (virHashValueFree): New function. * src/util/virhash.c (virHashValueFree): Implement it. * src/util/virobject.h (virObjectFreeHashData): New function. * src/libvirt_private.syms (virhash.h, virobject.h): Export them. * src/nwfilter/nwfilter_learnipaddr.c (virNWFilterLearnInit): Use common function. * src/qemu/qemu_capabilities.c (virQEMUCapsCacheNew): Likewise. * src/qemu/qemu_command.c (qemuDomainCCWAddressSetCreate): Likewise. * src/qemu/qemu_monitor.c (qemuMonitorGetBlockInfo): Likewise. * src/qemu/qemu_process.c (qemuProcessWaitForMonitor): Likewise. * src/util/virclosecallbacks.c (virCloseCallbacksNew): Likewise. * src/util/virkeyfile.c (virKeyFileParseGroup): Likewise. * tests/qemumonitorjsontest.c (testQemuMonitorJSONqemuMonitorJSONGetBlockInfo): Likewise. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 25 3月, 2014 1 次提交
-
-
由 Ján Tomko 提交于
-
- 18 3月, 2014 2 次提交
-
-
由 Daniel P. Berrange 提交于
Any source file which calls the logging APIs now needs to have a VIR_LOG_INIT("source.name") declaration at the start of the file. This provides a static variable of the virLogSource type. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The dtrace probe macros rely on the logging API. We can't make the internal.h header include the virlog.h header though since that'd be a circular include. Instead simply split the dtrace probes into their own header file, since there's no compelling reason for them to be in the main internal.h header. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 13 12月, 2013 1 次提交
-
-
由 Eric Blake 提交于
Recent changes to events (commit 8a29ffcf) resulted in new compile failures on some targets (such as ARM OMAP5): conf/domain_event.c: In function 'virDomainEventDispatchDefaultFunc': conf/domain_event.c:1198:30: error: cast increases required alignment of target type [-Werror=cast-align] conf/domain_event.c:1314:34: error: cast increases required alignment of target type [-Werror=cast-align] cc1: all warnings being treated as errors The error is due to alignment; the base class is merely aligned to the worst of 'int' and 'void*', while the child class must be aligned to a 'long long'. The solution is to include a 'long long' (and for good measure, a function pointer) in the base class to ensure correct alignment regardless of what a child class may add, but to wrap the inclusion in a union so as to not incur any wasted space. On a typical x86_64 platform, the base class remains 16 bytes; on i686, the base class remains 12 bytes; and on the impacted ARM platform, the base class grows from 12 bytes to 16 bytes due to the increase of alignment from 4 to 8 bytes. Reported by Michele Paolino and others. * src/util/virobject.h (_virObject): Use a union to ensure that subclasses never have stricter alignment than the parent. * src/util/virobject.c (virObjectNew, virObjectUnref) (virObjectRef): Adjust clients. * src/libvirt.c (virConnectRef, virDomainRef, virNetworkRef) (virInterfaceRef, virStoragePoolRef, virStorageVolRef) (virNodeDeviceRef, virSecretRef, virStreamRef, virNWFilterRef) (virDomainSnapshotRef): Likewise. * src/qemu/qemu_monitor.c (qemuMonitorOpenInternal) (qemuMonitorClose): Likewise. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 10 7月, 2013 1 次提交
-
-
由 Michal Privoznik 提交于
-
- 24 5月, 2013 1 次提交
-
-
由 Michal Privoznik 提交于
-
- 08 4月, 2013 1 次提交
-
-
由 Daniel P. Berrange 提交于
The current way virObject instances are allocated using VIR_ALLOC_N causes alignment warnings util/virobject.c: In function 'virObjectNew': util/virobject.c:195:11: error: cast increases required alignment of target type [-Werror=cast-align] Changing to use VIR_ALLOC_VAR will avoid the need todo the casts entirely. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-