[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.