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

[Thanos Makatos <thanos.makatos@xxxxxxxxxx>]

> > 4. tapback: a user space daemon that acts as the back-end of each
> virtual
> >    block device: it monitors XenStore for the block front-end's state
> changes,
> >    creates/destroys the shared ring, and instructs the tapdisk to
> connect
> >    to/disconnect from the shared ring. It also communicates to the
> block
> >    front-end required parameters (e.g. block device size in sectors)
> via
> >    XenStore.
> 
> There is 1 tapdisk per VBD but how many tapbacks are there? One per VBD
> as well or one per domain or per driver domain?

There is one tapback daemon in total, serving all VBDs/domains.

The tapback daemon sets a XenStore watch to "backend/<device type>" to serve 
VBD creations for completely new domains, and then sets an additional watch to 
the front-end state path for each VBD. I guess there could be one tapback 
daemon detecting completely new domains, responsible for spawning tapback 
daemons designated to a specific domain/VBD. I'm not sure of the implications 
of this approach, though. (We could also have one thread designated to each 
domain/VBD.) Is there a particular reason why a single tapback daemon wouldn't 
suffice?

> 
> Is tapback involved in things after the ring has been setup and it has
> instructed tapdisk to use it? i.e. is it on the datapath at all?

The tapback daemon is involved only for running the Xenbus protocol when the 
front-end is set up/torn down -- no participation in the data path.

> 
> Ian.

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