Messages in this thread | | | Date | Wed, 2 Mar 2016 09:37:48 -0800 | From | Jaegeuk Kim <> | Subject | Re: [PATCH] fs/crypto: make crypto.c explicitly non-modular |
| |
Hi Paul,
On Mon, Feb 29, 2016 at 09:31:59AM -0500, Paul Gortmaker wrote: > [Re: [PATCH] fs/crypto: make crypto.c explicitly non-modular] On 29/02/2016 (Mon 10:56) Arnd Bergmann wrote: > > > 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. > > It wasn't that obvious to me, and at the risk of repeating myself, I'll > always default to making the code consistent with existing functionality > vs. making assumptions about what was intended and implicitly adding new > functionality that may be invalid for reasons I'd never spot. > > Of course authors, and maintainers are welcome to chime in and steer it > one way or another as per the PCI patches.
Meanwhile, I've modified and tested fscrypt as a module, as Arnd commented. I'll submit v3 to resolve this inconsistency. Thank you for the point that I missed. > > Paul. > -- > > > > > Arnd
| |