[libvirt] anyone implementing host device enumeration?

[Daniel P. Berrange]

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 :|