Re: [Xen-API] [Xen-devel] [PATCH 0 of 9 RFC v2] blktap3: Introduce a small subset of blktap3 files

[Thanos Makatos <thanos.makatos@xxxxxxxxxx>]

> In fact I'm wondering why the tapback daemon does all the ring setup,
> xenbus negotiation anyway. It could just watch "backend/<device-type>"
> and when it sees a new backend/<device-type>/<domid>/<devid> fork a new
> "tapdisk --domain <domid> --devid <devid>" and have tapdisk take care
> of the protocol entirely. Saves a bunch of messaging back and forth I
> think.
> 
> I don't have a problem with the existing model, it just strikes me as a
> bit odd (but then I don't really know the architecture)
> 
> Ian.

I'm not aware of any particular reason for this design option. However, this 
may turn out to be more interesting/complicated -- I'm including xen-api.

In the existing blktap3 prototype, when libxl starts a domain it also spawns 
the tapdisk. When tapback (formerly known as xenio) detects in XenStore that a 
front-end wants to connect to the VBD, it needs to locate which tapdisk is 
designated to serve the corresponding back-end file in order to instruct the 
tapdisk to connect to the ring. It seems that there is a number of ways for 
tapback to figure out which tapdisk it must use. I'm not sure whether all these 
alternatives are possible (please correct me if not), or whether all the 
necessary information is already written to XenStore.
* When libxl spawns the tapdisk, it instructs it to attach to the back-end 
file. Then, it associates the process ID of the tapdisk with the domain and 
device Ids (I assume by writing all this to XenStore). When tapback needs to 
figure out which tapdisk to use, it knows the domain and devices ids so all it 
has to do is to check XenStore for the corresponding tapdisk.
* When libxl spawns the tapdisk, it supplies to it the device and domain ID. It 
can also tell it which back-end file to use, or write this to XenStore. Tapback 
can then query all running tapdisk processes and select the one having the 
specified domain/device ID.

It seems that having tapback spawning the tapdisk is simpler, though tapback 
needs to tell tapdisk which back-end file to use, so it seems that libxl needs 
to associate the back-end file with the domain and device ids -- I guess this 
can only be achieved by having libxl writing all this to XenStore. Tapdisk will 
then take care of running the rest of the XenBus protocol.

Which solution is best, given that:
* multiple front-ends attached to the same VBD may be desirable
* VHD snapshot/coalesce operations need to figure out which tapdisks to 
pause/refresh
* various race conditions should be avoided (?)
* other?

_______________________________________________
Xen-api mailing list
Xen-api@xxxxxxxxxxxxx
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api