Re: [Xen-devel] [DOC v2] Xen transport for 9pfs

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Mon, Dec 05, 2016 at 05:33:23PM -0800, Stefano Stabellini wrote:
[...]
> ## Xenstore
> 
> The frontend and the backend connect via xenstore to exchange
> information. The toolstack creates front and back nodes with state
> [XenbusStateInitialising]. The protocol node name is **9pfs**.
> 
> Multiple rings are supported for each frontend and backend connection.
> 

It would help if you can state if a specific node is mandatory or
optional.

> ### Frontend XenBus Nodes
> ### Backend XenBus Nodes

[...]

> The producer always notifies the consumer after incrementing **prod**.
> However in some circumstances the producer is allowed not to notify the
> consumer, just as a performance improvement, and still maintain
> correctness. These are the steps to do it: after incrementing *prod*,
> the producer reads *cons* a second time; if the value is changed from
> the previous read and it is different from *prod* before the update,
> then the notification can be avoided. These are the producer steps, with
> the optimization:
> 
> - read *prod* (old_prod), *cons* (old_cons) from shared memory
> - general memory barrier
> - verify *prod* against local copy (consumer shouldn't change it)
> - write to array at position *prod* up to *cons*, wrapping around the circular
>   buffer when necessary
> - write memory barrier
> - increase *prod* (new_prod)
> - general memory barrier
> - read *cons* (new_cons)
> - if new_cons == old_cons or new_cons == old_prod, then notify the
>   consumer
> 

I think it would be valuable to extract this section to a generic "how
to write driver" doc. But that's probably something for another day.

Wei.

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