Re: [libvirt] anyone implementing host device enumeration?
On Thu, 2008-10-09 at 18:01 +0100, Daniel P. Berrange wrote:
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
Well ... uhh ... no. :-o
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.
Okay, I'll buy that. And (now) I see what you mean about the differing
object lifetime.
... In fact (perhaps I shouldn't be admitting this publicly), your whole
public-obj/Obj scheme now finally makes sense to me! The public objs
are really just a kind of handle to the private Objs, and they exist
independently of one another. public objs belong to the apps, private
Objs to the appropriate driver. And (now that I look at the Xen
driver), I finally understand that there are stateless drivers.
In fact, both the devkit and HAL node-dev drivers need to be stateful
(since the device name isn't a reasonable handle for either devkit or
HAL devices), so I'm creating a virNodeDeviceObj as well as a
virNodeDeviceDef.
Dave