Re: [Xen-devel] /proc/xen/xenbus supports watch?

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

> But but but... it doesn't *help*.  That's the entire point!
>
> OK, please describe, in simple terms, why you think save/restore is
> different if we multiplex across a single transport?
Well, maybe there's not so much in it after all. I'll assume here we go 
for the 'xenstored forgets all state, and clients get EAGAIN at the 
first available opportunity' approach.
If we mux on a single transport:
 1. The shared transport page is set up automatically in xenstored when 
the domain is restored. Xenstored has forgotten about any in-progress 
transactions.
 2.  The xenbus driver marks all file handles (or transaction 
structures, or whatever it uses to track local state for each local 
transaction) as doomed. Any further activity on those transactions 
returns EAGAIN rather than passing thru to xenstored.
 3. That's it! Clients detect failure and retry.

If we have page per transaction:
 1. Same as (1) above.
 2. Same as (2) above, but free the per-transaction transport page.
 3. Same as (3) above.

However, I'm not clear yet what each separate transport page 
represents. Is it a single transaction, or a connection that stores 
multiple watches and one transaction at a time? If the latter, 
save/restore gets a bit harder as the transport pages must be 
automatically re-registered and watches re-registered...
 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel