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