Re: [Xen-devel] [PATCH 4 of 7 v2] blktap3/tapback: Introduce back-end XenStore path handler

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2013-01-04 at 12:14 +0000, Thanos Makatos wrote:
> This patch introduces the handler executed when the back-end XenStore path 
> gets
> modified. A back-end XenStore path is modified as a result of a device
> creation/removal request. The device is created/removed depending on whether
> its path exists/does not exist in XenStore.
> 
> Creating a device comprises creating the in-memory representation of it and
> adding it to the list of devices, locating the tapdisk designated to serve
> this VBD, and setting a XenStore watch to the front-end path of the
> newly-created device.
> 
> Deleting a device comprises removing that XenStore watch and deallocating its
> in-memory representation.
> 
> The main issues in this patch are the following:
> 
> * Function tapback_backend_handle_backend_watch calls tapback_backend_scan
>   even when we know in which domain a device changed, wouldn't it make sense
>   from a performance perspective to only probe the devices of that domain
>   instead of probing ALL devices of ALL domains?

I suppose it would...

> * Is there a race condition between the tapback daemon and the toolstack
>   regarding partially brought up devices? I'm trying to figure out what the
>   "serial" thing does (check functions tapback_backend_create_device and
>   tapback_backend_probe_device) but I don't get it. Even if there is such a
>   race condition, I'm not convinced that the way that "serial" thing is
>   implemented fixes it.

There isn't a "serial thing" in the generic protocol so I don't know
what that is but normally the toolstack will write the entire initial
backend/frontend directories in xenstore in a single transaction.

Also I think it is customary for backends to ignore directories with no
"state" node -- and toolstacks write that last.

(Having now seen the serial stuff you refer I've no idea WTF it is
trying to do either ;-))



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