Currently there are many types of modules that are autoloaded from open-ended patterns:
- if_xyz.kmod, when you do `ifconfig xyzN create' - xyzfs.kmod, when you do `mount -t xyzfs ...' - xyzdev.kmod, when you open /dev/xyzdevN and there's an entry in sys/conf/majors for it - npf_alg_xyz.kmod, when you configure npf with an ALG xyz If a module is autoloaded, the kernel will automatically try to _unload_ the module after 10sec by default. There is a mechanism for modules to opt out of autounload: on MODULE_CMD_AUTOUNLOAD the xyz_modcmd function can return some value other than 0 or ENOTTY. However, many modules have not been audited for unload, let alone autounload, and many xyz_modcmd functions have been copied & pasted from existing ones that only handle MODULE_CMD_INIT/FINI and return ENOTTY for all else, and often the unload routines aren't tested very thoroughly. These modules are not safe to autounload -- if the module has any resources in use it might corrupt kernel memory to do so -- but the kernel may do so anyway. I propose we remove the assumption that ENOTTY means no objection, and switch from opt-out to opt-in: if a module _has_ been audited to verify MODULE_CMD_AUTOUNLOAD is safe, it can return 0; otherwise it will never be autounloaded, even if the author forgot to deny MODULE_CMD_AUTOUNLOAD. Some modules might still be unsafe to unload, which is a bug -- but at least this way accidentally creating the wrong network interface or opening the wrong device won't set a ten-second time-bomb for the system like I occasionally stumble upon in the status quo. Some modules have had their unload routines tested extensively, like the exec modules which are all autoloaded -- and autounloaded -- regularly. These can probably be quickly opted into unload. Other modules can be audited as time permits, and the changes to permit MODULE_CMD_AUTOUNLOAD can be pulled up, but if you copy & paste an existing xyz_modcmd and forget to forbid MODULE_CMD_AUTOUNLOAD the result is safer by default. Objections?
