Re: [Xen-devel] Driver domains communication protocol proposal

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxx [mailto:xen-devel-
> bounces@xxxxxxxxxxxxx] On Behalf Of Ian Jackson
> Sent: 04 April 2012 16:47
> To: xen-devel@xxxxxxxxxxxxx
> Subject: [Xen-devel] Driver domains communication protocol proposal
> 
> During some discussions and handwaving, including discussions with some
> experts on the Xenserver/XCP storage architecture, we came up with what
> we think might be a plausible proposal for an architecture for
> communication between toolstack and driver domain, for storage at least.
> 
> I offered to write it up.  The abstract proposal is as I understand the
> consensus from our conversation.  The concrete protocol is my own
> invention.
> 
> Please comments.  After a round of review here we should consider
> whether some of the assumptions need review from the communities
> involved in "other" backends (particularly, the BSDs).
> 
> (FAOD the implementation of something like this is not 4.3 material, but it
> may inform some API decisions etc. we take in 4.2.)
> 

I'm wondering how we should deal with driver domain re-starts (possibly because 
of a crash). One of the compelling reasons for using driver domains is the 
ability to re-start them, possibly transparently to the frontend.
If a driver domain were to crash, I guess it would be the responsibility of the 
tools to notice this and build a new one as quickly as possible. A frontend 
could notice the loss of a driver domain backend by, presumably a backend state 
watch firing followed by an inability to read the backend state key, as 
presumably a clean unplug should go through the usual closing->closed dance 
first. The frontend could then, perhaps, stall I/O while the tools build a new 
driver domain and re-build communications when it notices the 
<frontend>/backend key get updated by the tools. Does that sequence sound 
plausible?

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel