[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Module auto-unloading (was Re: CVS commit: src/sys/arch/x86/x86)
We could use the reference counter in struct cfdriver to keep driver
modules "busy", but I'm not sure if the system can figure out what's
unneeded if a "needed" driver might be one for a hotpluggable device.
Would you treat those drivers differently? What about drivers (if_ath_pci
comes to mind) that can be used both for fixed or hotplug devices?
I played around with driver module autoloading a while back, and it worked
pretty well but the implementation I came up with required duplicating
match data in <module>.plist.
On Tue, 18 Oct 2011, Warner Losh wrote:
On Oct 18, 2011, at 4:39 AM, Jared McNeill wrote:
I would argue that any manually loaded module shouldn't be autounloaded. What
do you think about flagging modules as autoloaded and only autounloading the
If I "manually" load a dozen drivers at boot because I have a dozen different boards with
different devices. I'd kinda like the system to "automatically" figure out what isn't
needed and unload those drivers.
On Tue, 18 Oct 2011, Jukka Ruohonen wrote:
On Tue, Oct 18, 2011 at 08:43:46AM +0200, Marc Balmer wrote:
Am 18.10.11 06:27, schrieb Jukka Ruohonen:
On Tue, Oct 18, 2011 at 12:07:45AM +0000, Jared D. McNeill wrote:
Module Name: src
Committed By: jmcneill
Date: Tue Oct 18 00:07:45 UTC 2011
don't allow module autounload
I wonder should autounloading be prohibited for all driver-class modules?
Why? When the parent goes away, why not autounload a driver?
I am not sure. But have we thought about all the consequences and corner-
cases? Unloading happens while modifying hardware state? Deferred calls
in the drivers? And so on? To me it also seems that if I manually load
a driver-module, I expect it to stay loaded until I unload it.
Main Index |
Thread Index |