Re: [libvirt] anyone implementing host device enumeration?
On Thu, Oct 09, 2008 at 12:25:18PM -0400, David Lively wrote:
Hi Daniel -
I'm implementing virNodeDeviceDef, as suggested, but I just noticed
something that really bothers me. In a nutshell, it's that the current
implementation of this scheme unnecessarily increases the (time)
complexity of O(1) operations to O(n).
For example, take virDomainGetXMLDesc(). One would think dumping the
XML descriptor for a domain object we have in hand would be O(1), but in
fact, it's O(n) (where n is the number of domains with the same driver),
because qemudDomainDumpXML must find the DomainObjPtr (from which it can
get the def). I suppose this lookup could be made O(log n) if the
domains were sorted by UUID on the list, but the fact remains that
lookup could be eliminated entirely.
Sure the lookup algorithm is O(n), but have you actually got real
world benchmarks showing this is the serious bottleneck? In the XML
dump example, the time to lookup the object is likely dwarfed by the
time to generate the XML doc, or to talk to the QEMU monitor.
IMHO, optimizing this is overkill. Worst case we can just hash on
the UUID if it ever provdes a problem.
Perhaps it's just a matter of allowing the "public"
objects
(virDomain, virNetwork, etc.) to hold a pointer to their optional (never
used by remote driver, for example) private state objects. So I guess
I'm suggesting adding a void * to each of the public objects, which
drivers can use for this purpose. I'll go ahead and do this for
NodeDevices in the next incarnation of this patch to show you what I
mean. (It won't be hard go to the conventional lookup impl if this
turns out to be a bad idea.)
No please don't do that. We really need to keep the hard separation
between the public vir{Domain,Network,Storage,Node}Ptr objects, and
the internal objects completely separated. The only association
should be via the various unique keys - ID, Name & UUID as appropriate.
The public objects do not neccessarily have the same lifecycle as
the internal object - eg, an app can hold onto the public object
even after the internal representation has been killed off.
Keeping a reference from the public to private objects, means we also
need to have a reverse references from priate to public objects, so we
can kill off the references when objects go away. This also means we
need to have complex locking from the internal drivers to the public
objects which for thread safety which I really do not want.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|