Re: Autoloading of pseudo-device modules

[Greg Oster <oster%cs.usask.ca@localhost>]

Adam Hamsik writes:
> 
> On Jan,Friday 16 2009, at 2:42 AM, Adam Hamsik wrote:
> 
> > Hi,
> > On Jan,Wednesday 14 2009, at 6:50 PM, Antti Kantee wrote:
> >
> >> On Wed Jan 14 2009 at 14:54:49 +0100, Adam Hamsik wrote:
> >>> Because dm driver is not enabled in kernel yet, and it is  
> >>> installed as
> >>> new style module.
> >>> I have written this small patch [1] to subr_devsw.c which enable  
> >>> auto-
> >>> loading of pseudo-device
> >>> drivers. In my patch I'm changing cdev_open/bdev_open routines to  
> >>> try
> >>> to load module if they
> >>> was not able to look up it.
> >>
> >> Good, we need this feature.
> >>
> >>> I have also converted some of our well known pseudo-drivers to  
> >>> modules
> >>> so we can remove them from kernel.
> >>> [2], [3], [4]. I don't have cgd or raidframe* setup but I will  
> >>> test it
> >>> more.
> >>
> >> Both take a few minutes to set up, so I don't think this is a very
> >> convincing excuse for lack of superficial testing.
> >>
> >
> > I will do it when this patch will stabilise little bit. I have  
> > university
> > exams now so I don't have too much time.
> 
> 
> If there are no serious objections I would like to commit this patch  
> against
> devsw and modules, too(if raidframe module doesn't work yet we can at  
> least test it).

The RAIDframe module bits should not be committed  -- the code will 
not work, and it doesn't need to be in the tree for testing for me to 
determine that.  Before any RAIDframe module code goes in it needs to 
be thoroughly tested... 

Some thought needs to also be given to whether or not the different 
RAID types should be modularized as well.. (e.g. to avoid loading 
RAID 5 bits on a box with only RAID 1 sets..)

Later...

Greg Oster