Re: [libvirt] [PATCH v2 5/8] util: Introduce virObjectPoolableHashElement
On Fri, Jun 02, 2017 at 06:17:19 -0400, John Ferlan wrote:
Add a new virObjectLockable child which will be used to more
generically
describe driver objects. Eventually these objects will be placed into a
more generic hash table object which will take care of object mgmt functions.
Each virObjectPoolableHashElement will have a primaryKey (required) and a
secondaryKey (optional) which can be used to insert the same object into
two hash tables for faster lookups.
Signed-off-by: John Ferlan <jferlan(a)redhat.com>
---
src/libvirt_private.syms | 2 ++
src/util/virobject.c | 76 +++++++++++++++++++++++++++++++++++++++++++++++-
src/util/virobject.h | 17 +++++++++++
3 files changed, 94 insertions(+), 1 deletion(-)
[...]
VIR_OBJECT_USAGE_PRINT_WARNING(anyobj, virObjectLockableClass);
diff --git a/src/util/virobject.h b/src/util/virobject.h
index f4c292b..e29dae7 100644
--- a/src/util/virobject.h
+++ b/src/util/virobject.h
[...]
@@ -59,9 +62,17 @@ struct _virObjectLockable {
virMutex lock;
};
+struct _virObjectPoolableHashElement {
+ virObjectLockable parent;
+
+ char *primaryKey;
+ char *secondaryKey;
+};
I'm afraid that this abstraction is going too far.
Putting dissimilar objects into a single hash does not really make sense
in any way in libvirt. Without the need to put dissimilar objects into a
single hash I don't really see value in abstracting the identifiers of
the objects into opaque things like 'primaryKey'.
Refering to the objects by these oaque terms will cause confusion, and
thus will still require wrappers to de-confuse readers of the code.
An additional worry is the optionality of the secondary key. This hints
that the objects are so dissimilar that they don't have two names in
common.
Attachments:
- signature.asc (application/pgp-signature — 833 bytes)