WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Propose "xen_init()" call first thing in Xen drivers

To: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Subject: Re: [Xen-devel] Propose "xen_init()" call first thing in Xen drivers
From: Hollis Blanchard <hollisb@xxxxxxxxxx>
Date: Thu, 22 Sep 2005 14:55:08 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Matt Chapman <matthewc@xxxxxxxxxxxxxxx>
Delivery-date: Thu, 22 Sep 2005 19:53:52 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <516F50407E01324991DD6D07B0531AD5695F90@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: IBM Linux Technology Center
References: <516F50407E01324991DD6D07B0531AD5695F90@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.8.2
On Thursday 22 September 2005 14:20, Magenheimer, Dan (HP Labs Fort Collins) 
wrote:
> > What linker magic exactly? I don't understand the problem.
>
> IIRC, the problem arose because we moved xen/arch/xen/kernel
> to -sparse/drivers/xen/core (which is planned as part of
> the getting-into-the-linux process).  This changed the link
> order which had previously (by chance) linked the evtchn_init
> routine prior to any drivers/xen init routine.  If any
> of the drivers/xen init routines execute before evtchn_init,
> they fail.  Since we needed a test for "running_on_xen"
> anyway, we (Matt) combined the two solutions into one architecturally
> independent abstraction.

Oh, well, there's the problem: module_init(evtchn_init). That means 
evtchn_init will be called in arbitrary (link) order, intermingled with the 
actual drivers (which are also using module_init).

evtchn_init() can be built in and made a subsys_initcall, or there needs to be 
an explicit module dependency: e.g. request_module("evtchn").

http://xenbits.xensource.com/ext/xenlinux-ia64-2.6.12.hg?cmd=file;filenode=769f15e75bbd990900b352a3f9d50562d9e399df;file=drivers/xen/core/xenia64_init.c

As for xen_start_info in the above URL, why don't you make sure arch code sets 
that up before drivers are loaded? You can turn your existing xen_init() into 
an arch_initcall.

-- 
Hollis Blanchard
IBM Linux Technology Center

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

<Prev in Thread] Current Thread [Next in Thread>