From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH] xencommons: Attempt to load blktap driver Date: Wed, 16 May 2012 11:49:24 +0100 Message-ID: <4FB38634.7050807@eu.citrix.com> References: <4FB29D6F0200007800083E81@nat28.tlf.novell.com> <4FB28295.8020905@eu.citrix.com> <1337156497.27824.2.camel@zakaz.uk.xensource.com> <4FB3886A020000780008402F@nat28.tlf.novell.com> <1337159777.27824.39.camel@zakaz.uk.xensource.com> <4FB394AE0200007800084098@nat28.tlf.novell.com> <1337162232.27824.55.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1337162232.27824.55.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Jan Beulich , xen-devel List-Id: xen-devel@lists.xenproject.org On 16/05/12 10:57, Ian Campbell wrote: >>> The blktap detection code is necessarily OS-specific. I previously >>> discounted it because of the possibility of a race between the >>> completion of modprobe and the driver actually registering enough for >>> detection to succeed. Maybe I was too pessimistic or someone has a >>> bright idea? >> modprobe only exits when the driver's init function completed, >> at which point the driver can be expected to be in a usable state. > OK, so maybe that works then. So what's the plan? Options seem to be: 1. Put this on the blocker list, so it definitely gets done before release 2. Accept the patch that started this thread (or a version of it), and put "do it right" on the "nice-to-have" list. I can do it if I get a chance. 3. Someone can volunteer who can prioritize it. -George