[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] RFC: removing hardcoded "modprobe blktap" in xencommons
On Fri, Jul 12, 2013 at 02:00:20PM -0400, Konrad Rzeszutek Wilk wrote: > On Fri, Jul 12, 2013 at 05:12:55PM +0100, Wei Liu wrote: > > Hi Jan > > > > 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). > > > > 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")'. > Yes I saw that. > If any user application did an fopen("/dev/XYZ") then said module would be > automatically loaded. > I don't know much about blktap, but this doesn't seem to work in the first place, otherwise we would not have to add that modprobe in xencommons. As for other modules I agree that they should be handled with the autoloading scheme. However blktap is unmaintained I don't think how feasible it is to "fix" blktap. > > > > And, why do you think it is bad to have "modprobe blktap" in xencommons? > > What about not removing it? > > > > > > Wei. > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@xxxxxxxxxxxxx > > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |