Re: Autoloading of pseudo-device modules

[Adam Hamsik <haaaad%gmail.com@localhost>]

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.

> > There is one outstanding problem with loading device drivers which
> > need argument in kernel
> > config file e.g. pseudo-device cgd 4, I do not know how to pass this
> > number to modcmd function
> > which calls driver attach routine. With removing these drivers from
> > kernel we can shrink it by
> > 200k.
>
> You should fix cgd to not require a static configuration.  Previously
> users had to edit the kernel config file if they wanted more.  Now  
> they
> have to edit the source.  Making something a module is not a goal for
> which we should sacrifice usability.

I will look at it for both ccd and cgd.
> If you don't find a name, you still return success?
Fixed.

> Where is the major/name loaded into the reverse lookup table in the
> first place?  Or can't you load devices which weren't available when
> the kernel was config'd?

I need simple way how to translate device major number to device name.  
So
I can load device module. Reverse lookup table is created from all  
majors
files in kernel by config.
> What prevents an unload between the load and the lookup?
Nothing I'm not sure how to do that. Holding module_lock is during whole
devsw_do_load is probably bad idea.

> And just thinking out loud: would be cool if all the devices  
> attached to
> devsw the same way (i.e. dynamically).  Then there would be no  
> separate
> hardconfig'd devices and dynamically attached ones, i.e. no "second
> class citizens".  But that's not really related to your goal.

That would be great. We can probably add devsw's generated by config to
some dynamic list from devsw_init.

Attachment: devsw.diff
Description: Binary data

Regards

Adam.