From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: RFC: removing hardcoded "modprobe blktap" in xencommons Date: Mon, 15 Jul 2013 07:13:46 +0100 Message-ID: <51E3AF3A02000078000E4CA8@nat28.tlf.novell.com> References: <20130712161255.GB4409@zion.uk.xensource.com> <20130712180020.GB9829@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130712180020.GB9829@phenom.dumpdata.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wei Liu , Konrad Rzeszutek Wilk Cc: George Dunlap , Ian Jackson , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org >>> On 12.07.13 at 20:00, Konrad Rzeszutek Wilk wrote: > On Fri, Jul 12, 2013 at 05:12:55PM +0100, Wei Liu wrote: >> Back before 4.3 release you complaint about the hardcoded modprobe for >> blktap / blktap2 in xencommons script. I started to look into it this >> week and tried to do this modprobe automatically in libxl (that's the >> idea we discussed before 4.3 IIRC). But you understand that the complaint isn't just about blktap, but about _all_ of the modprobes there. >> Unfortunately I didn't manage to find any canonical documents on how a >> user space process can trigger a modprobe. I've looked at kernel >> documentations and couldn't find any. Do you have any reference on how >> to do that? > > Ian and George talked to me on IRC about this. What we found (thanks for > Greg KH's help) was that you can use 'MODULE_ALIAS("devname:XYZ")'. > > If any user application did an fopen("/dev/XYZ") then said module would be > automatically loaded. This works only for drivers for devices with known major:minor, as otherwise you have a chicken-and-egg problem between udev needing a way to determine the major:minor pair to create the /dev node, and the driver wanting to be loaded via udev rules. Which particularly means that - afaict - drivers (like blktap) using MISC_DYNAMIC_MINOR aren't suitable for this; I'll be happily corrected if there nevertheless is a way... Yet I don't see why this would be needed for backends anyway: The tool stack knows which backend it needs, and hence can modprobe its xen-backend:* alias easily enough (i.e. still without knowing the actual module name). Jan