Messages in this thread | | | From | Arnd Bergmann <> | Subject | Re: [PATCH] fs/crypto: make crypto.c explicitly non-modular | Date | Mon, 29 Feb 2016 10:56:50 +0100 |
| |
On Saturday 27 February 2016 15:20:49 Paul Gortmaker wrote: > As of commit 47134e6084f70fdf4381af75d4569cec6c7ebd50 ("fs crypto: > add Makefile and Kconfig") the compile of fs/crypto/crypto.c tripped > my local audit for non-modules using modular infrastructure vs. their > built in counterparts. > > The Kconfig currently controlling compilation of this code is: > > config FS_ENCRYPTION > bool "FS Encryption (Per-file encryption)" > > combined with: > > obj-$(CONFIG_FS_ENCRYPTION) += crypto.o policy.o keyinfo.o > > ...meaning that it currently is not being built as a module by anyone. > > Lets remove the modular code that is essentially orphaned, so that > when reading the driver there is no doubt it is builtin-only. > > Since module_init translates to device_initcall in the non-modular > case, the use of fs_initcall (which seems appropriate for fs code) > means the init comes slightly earlier. However boot testing an > x86-64 defconfig didn't show this to be causing any issues. > > We replace module.h with moduleparam.h since the file does declare > some module parameters, and leaving them as such is currently the > easiest way to remain compatible with existing boot arg use cases. >
So why not make the option a 'tristate' instead? It looks like that was intended here, and we should always try to make all code loadable as modules if possible.
Arnd
| |