[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

> > 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 

> 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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.