Date: Fri, 9 Jul 2004 10:32:15 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Brian Somers <brian@Awfulhak.org> Cc: Poul-Henning Kamp <phk@phk.freebsd.dk> Subject: Re: [RFC] kldunload -f argument. Message-ID: <Pine.NEB.3.96L.1040709102423.60816K-100000@fledge.watson.org> In-Reply-To: <20040709115858.47efb729@dev.lan.Awfulhak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 9 Jul 2004, Brian Somers wrote: > > I'm not sure I see any real-world application for this ? Can you give an > > example ? Why would you load a module and not use it ? > > I can't think of any non-development-environment reasons unless there's > room for modules being loaded early to be able to make assumptions about > their environment at ACTIVATE time (such as a root filesystem being > available). We actually have an example in the form of snd_driver, which forces all the sound modules to load, with the intent that when you unload, the attached ones are left running. We also have a lot of functionality compiled into GENERIC that many people don't use or use only infrequently -- when that functionality is compiled into modules, we frequently automatically load modules during a file system mount, netgraph pieces, etc. When they're no longer in use, they hang around. In a world where we consistently load modules on demand, and those modules remain idle after use, it would be somewhat nice to be able to simply say "Ok, modules no longer needed, please unload yourselves". Note that other systems do this also -- Darwin loads a lot of hardware device drivers early in the boot so that they can detect any devices required for the boot. They then unload the unreferenced ones and allow the user space device pieces to reload them as needed for dynamic hardware arrival. > I guess if_tun.ko springs to mind. I can reliably unload it if I > quiesce it, kill all the ``Opened by PID N'' processes, then unload it. Note that "Opened by PID N" is actually unreliable if the process that opened the tunnel does anything tricky, including fork and exit after opening the tunnel. > The MOD_ACTIVATE becomes more useful when a module ends up in a > quiescent state for a long time - the user might want to change their > mind instead of only being allowed to [try to] unload the now useless > driver. > > Unless anyone's inspired to make any more pragmatic suggestions along > these lines though, it's probably sensible to just skip the ACTIVATE > idea :*) Well, I think it's important to think of all this as a state machine. During a clean and happy module unload, quiesce->unload may be a short jump, but in a less happy unload, it may not be. If we live in a world of auto-loading modules on demand, we can't assume that the loading will happen at a convenient time, so we need to assume it's possible for it to happen while the module is already transitioning from the fully functional state towards the unloaded state. We either need to wait for it to finish, then load the module again, or some other transition scheme that results in the process loading the module not being told "Take a hike". Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040709102423.60816K-100000>