tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Autoloading of pseudo-device modules

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

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

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?


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



Home | Main Index | Thread Index | Old Index