From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ewan Mellor <ewan@xensource.com>
Subject: Re: [PATCH] Paravirt framebuffer frontend kernel support
	[1/5]
Date: Thu, 2 Nov 2006 16:31:11 +0000
Message-ID: <20061102163111.GA5265@leeni.uk.xensource.com>
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>
	<20061102161955.GA7065@cam.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Return-path: <xen-devel-bounces@lists.xensource.com>
Content-Disposition: inline
In-Reply-To: <20061102161955.GA7065@cam.ac.uk>
List-Unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Steven Smith <sos22-xen@srcf.ucam.org>
Cc: xen-devel <xen-devel@lists.xensource.com>, Jeremy Katz <katzj@redhat.com>, aliguori <aliguori@mail.utexas.edu>, Markus Armbruster <armbru@redhat.com>, sos22@srcf.ucam.org
List-Id: xen-devel@lists.xenproject.org

On Thu, Nov 02, 2006 at 04:19:55PM +0000, Steven Smith wrote:

> > 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.
>=20
> 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.

This is what we do for blktap -- tools/examples/blktap just calls success
immediately, which writes "connected" into the store as you suggest.

Ewan.