On Thu, Oct 09, 2008 at 02:29:18PM -0400, David Lively wrote: > On Thu, 2008-10-09 at 18:01 +0100, Daniel P. Berrange wrote: > > > 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. I think its clear that the major thing lacking here is good documentation on the structure / internals of libvirt & its object/driver modelling. Until very recently it was pretty much every driver for itself. With the introduction of unified internal objects, we do now have some formal data structure, beyond just the driver.h API contracts. Until we document this its not surprising that people find it all rather opaque to understand Time for me to add a section to the website docs covering internal architecture in more detail... > 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. Great, that meshes with my mental model of things 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 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list