This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Automatic loading of xen-evtchn module in Xen 4.0.0?

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] Automatic loading of xen-evtchn module in Xen 4.0.0?
From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Date: Wed, 31 Mar 2010 09:40:40 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 31 Mar 2010 01:41:24 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4BB27F70.4090703@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <20100327173221.GJ1878@xxxxxxxxxxx> <4BAE8426.2050703@xxxxxxxx> <1269942297.10129.72385.camel@xxxxxxxxxxxxxxxxxxxxxx> <4BB27F70.4090703@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, 2010-03-30 at 23:47 +0100, Jeremy Fitzhardinge wrote:
> In practice there's no need to get very modular.  There's some value
> in 
> not loading all that backend support code unless we're actually dom0, 
> but I don't think there's much value in getting too fine-grained
> beyond that.  The actual drivers themselves are fairly ordinary, so
> they will probably just work if we can make xenbus generate the right
> request events.  Hm, I guess that would be the tool stack setting
> things up for a new domain, and requesting backend devices in the
> process, no? 

What happens with frontend hotplug, and should happen with backends too,
is that the xenbus core watches the "device" (or "backend") node in
xenstore (relative to the domain's root path "/local/domain/<X>/"). The
tools then create the necessary nodes to create the device which
triggers the xenstore watch, e.g. on a path starting with "vif", which
causes xenbus to generate a uevent with the necessary MODALIAS, see

The only problem with this is getting the initial xenbus-backend.ko
loaded so that it can do the watch -- perhaps that falls in the same
boat as evtchn and gntdev etc.


Xen-devel mailing list