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