On Tue, Oct 28, 2008 at 02:00:48PM -0400, Ben Guthro wrote: > I'm looking into implementing emitting events from the xen driver, and > I've run into a bit of a snag that I would like to discuss > > I've attached an old version of my patch for reference. > > However - from past discussions, I know that there was a desire to keep > the xen driver stateless. However, given the semantics of xenstore > watches, and events, I'm not sure I can see a way to preserve this. > > Lets take the case of creating a new domain: > XenStore gives us the functionaliity to put a watch on the special > xenstore key @introduceDomain. > However, when the watch fires - I see no mechanism of determining which > domain has been introduced. Indeed - looking at the code in xen which fires this event, I see no way to determine which is the new/old domain. > The only mechanism I can find is to maintain a list of domains, and > keep this up to date with events. > > So I'm wondering if anyone has any ideas, or if this will introduce > unwanted, but necessary state into the driver? This does appear to be the only option, it doesn't mean that we need to make Xen a fully stateful driver like QEMU. All this really amounts to is tracking a list of integer IDs or UUIDs - this is small enough that we can just keep track of it in the 'struct _xenUnifiedPrivate' which is per-virConnectPtr instance. When we get a introduceDomain watch, we'd just need to re-query for the list of IDs and compare to figure out what's new/old. We only need do this tracking if we've got a domain event callback registered, so I think this is acceptable. 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