Re: [Xen-devel] [PATCH] Paravirt framebuffer frontend kernel support [1/5]

[Steven Smith <sos22-xen@xxxxxxxxxxxxx>]

> Okay, thanks.  Next stupid question: I'm looking for a *user space*
> xenbus_register_backend().  Where is it?
I don't think there is such a thing at the moment, just because we
don't currently have any userspace backends.

I think in your particularly case, the easiest thing is probably going
to be to get xend to set up a skeleton xenstore area for the frontend
in the usual way (see DevController.py and e.g. netif.py).  With a
normal in-kernel driver you'd be able to watch the relevant location
to notice when a new device is created, but you don't have a
permanently-running daemon, which makes that a bit tricky.  I think
it'd be okay to just fake the relevant entry in the store (set
${backend_path}/hotplug-status to connected) from the backend.  It's a
little skanky, but it should be adequate and reasonably
straightforward to implement.

Once you've got that, it should be easy to just do the usual state
machine directly in the backend:

-- Both front and back are put into Initialising by xend.
-- When the backend is ready, it goes to state InitWait and triggers
   the hotplug event.
-- When the frontend is ready, it sets up its area of the store, and goes to
   Initialised.
-- The backend notices this, connects to the ring, and goes to state
   Connected.
-- The frontend notices this, goes to Connected itself, and makes
   itself available to the rest of the operating system.

Teardown is usually started by the frontend, and goes like this:

-- Frontend goes to state Closing
-- Backend disconnects from the ring and goes to state Closing
-- Frontend disconnects from the ring and goes to state Closed
-- Backend goes to Closed and destroys itself, unless online=1 in the
   store, in which case it prepares for further connections.

Xend can also trigger backend teardown by simply deleting the frontend
area, e.g. if the frontend domain crashed.  The normal in-kernel
infrastructure calls otherend_changed with the state
XenbusStateUnknown in that case, which causes the backends to destroy
themselves.

Steven.

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel