I''m trying to work out how to correctly set up and tear down a shared memory connection between a FE and a BE domain using xenstore. I''ve looked at the blkback/blkfront code but it doesn''t seem to cover all the scenarios required for the FE and BE to be loadable modules so I''m trying to work out what is necessary from first principles. Having looked at the code, I''m assuming that I can rely on the following guarantees from xenstore: 1) Transactions can be used to perform a set of writes atomically. 2) Gathers can be used to perform a set of reads atomically. 3) A watch is guaranteed to fire after a change is made. These three guarantees are sufficient to construct a communication channel between a FE and BE domain but the resulting solution is somewhat complicated... The three guarantees above result in a communication channel where: 1) Messages can be represented by transactions and gathers. 2) Messages can be reordered: by the time a watch fires, multiple transactions may have completed and relative ordering is lost. 3) Messages can be redelivered: when a watch fires, data from previous transactions is still present in the store. 4) Messages sharing the same field names can overwrite one another: transactions writing the same keys will overwrite previous values even if a watch hasn''t yet completed on them. 5) Messages are not dropped unless overwritten as in 4. 6) Stale messages persist in the system indefinitely. 7) There is no explicit indication whether the other side is live. A solution can be constructed using the following features: 1) Use a unique for all time epoch number (e.g. large, randomly generated) to filter out stale messages. 2) Use sequence numbers within an epoch to preserve message ordering and guarantee exactly once delivery. 3) Use a unique namespace for the field names for every possible concurrent message (to avoid 4 above). 4) Use a heartbeat to detect whether the other side is live. Using these features it is possible to construct a reliable, in-order channel with exactly-once delivery which can detect channel up and down events. On top of this channel, it would then be relatively easy to send messages to pass the shared page info: 1) Wait for the channel to go up. 2) When you want to connect, send a connect message with the shared page info. 3) When you want to disconnect, send a disconnect message and wait for a disconnected message before releasing shared resources. 4) Stop using other side''s resources before replying with a disconnected message. 5) If the channel goes down, assume the other side is dead and has stopped using your resources. So, this kind of solution would allow me to have loadable and unloadable FE and BE modules and correctly establish and tear down the shared memory comms channel when the modules are loaded and unloaded. But, I don''t think it''s how anyone is intending for xenstore to be used. So, I''m wondering what other guarantees are provided which would allow me to construct a simpler solution. Anyone got any hints? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel