On Sep 6, 5:36am, Paul Goyette wrote: } On Sat, 22 May 2010, Adam Hamsik wrote: } } >> My specific questions: } >> } >> What actually triggers an autoload of a module? (There seem to be } >> very few places where module_autoload() is called.) } > } > Device module_autoloading is done in specfs_open. } } OK. So I guess there's no generic "Gee, the kernel just tried to } reference something that's not here, so maybe we can find a module to } resolve that reference."
How do you envision something like this working? Off the top of my head, I can't think of any way it could work. } >> What is the semantic difference between module_autoload() and a } >> "normal" module_load()? } > } > module_autoload happens automatically when you try to open device node } > which doesn't have device driver in kernel. } } My question was more along the lines of "what is the _difference_ } between module_load() vs module_autoload()?" Or even simpler, "Why do } both routines exist?" :) module_load() is for use by the modctl() syscall. module_autoload() is for when the kernel is autoloading something. As I mentioned previously module_autoload() checks the kern.module.autoload sysctl for permission and there are some path restrictions. } >> Does the code which calls either of these routines need to be } >> concerned with whether the module has been previously loaded? Is it } >> OK to load a module that has already been loaded? } >> } > } > I think that this is not possible and these routines return an error } > when you try to do that. } } That's OK, I'd expect the error. I can ignore that. I just need to be } sure that the previously-loaded module doesn't get "screwed up" from the } attempt to load it the second time. No, the "scan" to see if the module is already loaded happens before anything is done with the module to be loaded. } >> Given that there is a kernel thread that runs around and attempts to } >> unload any unreferenced modules that have been loaded "for a while", } > is it ever necessary or desirable to explicitly unload a module? } > } > It doesn't work this way there is a thread(workqueue) which try to } > unload module in first 300 seconds or mili seconds I can't remember } > now. But this thread or whatever is it doesn't unload modules older } > that set limit AFAIK. } } Hmmm, I must have misunderstood this code - time to go look again. At least some versions of the kernel will make multiple attempts. This can be demonstrated. Let the kernel autoload something like exec_elf32 (which will happen if you use a standard i386 GENERIC), set kern.module.verbose=1, then check /var/log/messages. However, I believe there was some talk about changing the way this works. I'm not sure how it works at this exact moment, or how it might work in the future. }-- End of excerpt from Paul Goyette