On Mon, Oct 02, 2017 at 09:14:36AM +0200, Geert Uytterhoeven wrote: > Now this has hit mainline, the "BIG_KEYS" Kconfig symbol appeared on my > radar. Is there any reason this cannot be tristate? > > The help text says: > > This option provides support for holding large keys within the kernel > (for example Kerberos ticket caches). The data may be stored out to > swapspace by tmpfs. > > If you are unsure as to whether this is required, answer N. > > So to save kernel size, I wan't to save N, but for a distro kernel that might > have Kerberos users, you currently need to say Y, while M would be nicer. > > The symbol seems to just control the build of security/keys/big_key.c, > which could use module_init() in the modular case. > I'm not sending a patch to change BIG_KEYS from bool to tristate, as this is > crypto, and I don't understand the full implications. > It's possible to have a key type in a module. In fact, some of the existing key types such as key_type_rxrpc can already be modular. But I don't think it really works as intended currently because there is no autoloading of key type modules. That is, if big_key was a module and you tried to add a key of type "big_key", the big_key module would *not* be automatically loaded, so the call would return -ENODEV. This could be fixed, I believe. (I also still need to convince myself that there aren't any race conditions in key type unregistering. It's a little weird how it changes the key type to the ".dead" key type, rather than pinning the key type in memory while it's still used.) Eric