On Sun, 19 Jan 2014, Paul Goyette wrote:
I would have expected config_cfdata_detach() to fail (with EBUSY) if the device was still open by someone. So I'm not sure who/what still owns allocations from the module's memory pool.
Hmmm, I guess I misunderstood something. It seems that there is no protection against detaching a device even when it is currently open.
A quick-and-dirty program that simply opens /dev/crypto and sleeps shows that the module gets unloaded.
I'm not sure at this point if the crypto(4) driver should implement a ref-count, or if a more generic solution should be created within the autoconf(9) framework.
For now, the best solution is to either leave the modules built-in, or manually load them (which prevents auto-unload).
------------------------------------------------------------------------- | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -------------------------------------------------------------------------
