Re: Autoloading of pseudo-device modules

[Andrew Doran <ad%netbsd.org@localhost>]

On Sat, Jan 24, 2009 at 03:30:54PM +0100, Adam Hamsik wrote:

> 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).
> We will probably need to re-implement this feature after mjf-devfs  
> branch merge,
> but until that day comes we can use this patch without any problems:).

The code belongs in specfs because all of the concurrency issues around
device nodes are managed there and in vfs. Nothing should be calling the
cdev or bdev functions directly other than specfs (I know there is existing
code that does this). Also:

- It is preferable to _not_ hold vnode locks when autoloading a module. 
  Ideally this means dropping the vnode's lock before calling
  module_autoload.

- I think that pooka pointed out the race condition with module loading in
  your code. The module can be gone by the time you try to use it. You can
  work around this by testing module_gen. 1) cache module_gen 2) try to
  autoload device driver 3) if it fails, and module_gen != cached copy,
  restart.

- Note that we do not yet have code to prevent removal of in-use devsw
  entries. A starting point would be to track opens by major number in
  specfs but there are a lot of issues to consider.

Thanks,
Andrew