From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755698AbcCBRhv (ORCPT ); Wed, 2 Mar 2016 12:37:51 -0500 Received: from mail.kernel.org ([198.145.29.136]:43737 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751062AbcCBRhu (ORCPT ); Wed, 2 Mar 2016 12:37:50 -0500 Date: Wed, 2 Mar 2016 09:37:48 -0800 From: Jaegeuk Kim To: Paul Gortmaker Cc: Arnd Bergmann , linux-kernel@vger.kernel.org Subject: Re: [PATCH] fs/crypto: make crypto.c explicitly non-modular Message-ID: <20160302173748.GA9395@jaegeuk.gateway> References: <1456604449-4666-1-git-send-email-paul.gortmaker@windriver.com> <17854864.AYbZjbhEmU@wuerfel> <20160229143158.GA18624@windriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160229143158.GA18624@windriver.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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