From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Smith Subject: Re: [PATCH] Paravirt framebuffer frontend kernel support [1/5] Date: Thu, 2 Nov 2006 16:19:55 +0000 Message-ID: <20061102161955.GA7065@cam.ac.uk> References: <1157227080.11059.38.camel@aglarond.local> <20060904090045.GA4812@cam.ac.uk> <87hczgrx07.fsf@pike.pond.sub.org> <20060910093801.GA1874@cam.ac.uk> <87wt7l68jm.fsf@pike.pond.sub.org> <871womyxa3.fsf@pike.pond.sub.org> <20061102103643.GB3879@leeni.uk.xensource.com> <87slh2xc0m.fsf@pike.pond.sub.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0051499984==" Return-path: In-Reply-To: <87slh2xc0m.fsf@pike.pond.sub.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Mime-version: 1.0 Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Markus Armbruster Cc: Jeremy Katz , aliguori , Ewan Mellor , xen-devel , sos22@srcf.ucam.org List-Id: xen-devel@lists.xenproject.org --===============0051499984== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > 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. --8t9RHnE3ZwKMSgU+ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFShqrO4S8/gLNrjcRAvZsAJkBHq/RQGJJRwdJVL2moLUrU9qwtwCgtfMs 9JBkYSi+sKSHQ42OGAXVM2c= =ugvm -----END PGP SIGNATURE----- --8t9RHnE3ZwKMSgU+-- --===============0051499984== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0051499984==--