Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753556AbbLLVc5 (ORCPT ); Sat, 12 Dec 2015 16:32:57 -0500 Received: from mail1.windriver.com ([147.11.146.13]:54022 "EHLO mail1.windriver.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753104AbbLLVcy (ORCPT ); Sat, 12 Dec 2015 16:32:54 -0500 From: Paul Gortmaker To: CC: Paul Gortmaker , Al Viro , Andrew Morton , David Howells , Eric Paris , Jan Kara , "J. Bruce Fields" , Jeff Layton , Josh Triplett , , Nadia Yvette Chambers , Peter Hurley Subject: [PATCH 00/10] fs: don't use module_init in non-modular code Date: Sat, 12 Dec 2015 16:30:02 -0500 Message-ID: <1449955812-10149-1-git-send-email-paul.gortmaker@windriver.com> X-Mailer: git-send-email 2.6.1 MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3059 Lines: 72 There are several reasons to not use module_init for code that can never be built as a module, but the big ones are: (1) it is easy to accidentally code up an unused module_exit function (2) it can be misleading when reading the source, thinking it can be modular when the Makefile and/or Kconfig prohibit it (3) it requires the include of the module.h header file which in turn includes nearly everything else. Here we convert some module_init() calls into fs_initcall(). In doing so we must note that this changes the init ordering slightly, since module_init() becomes device_initcall() in the non-modular case, and that comes after fs_initcall(). We could have used device_initcall here to strictly preserve the old ordering, but using that in the fs/ dir just seems wrong, and we have done similar minor init ordering shuffles in the past w/o fallout. Fortunately the code here is core fs code and not strictly a driver in the sense that a UART or GPIO driver is. So we don't have the concerns here with respect to limiting unbinding that we have when doing similar cleanups over there in the drivers/* dir. These commits were generated and tested on linux-next but I can put them on a v4.4-rc4 based branch if merge processing vs mail processing is desired. Given that they are largely trivial, I don't think the underlying baseline is all that important here. Cc: Al Viro Cc: Andrew Morton Cc: David Howells Cc: Eric Paris Cc: Jan Kara Cc: "J. Bruce Fields" Cc: Jeff Layton Cc: Josh Triplett Cc: linux-fsdevel@vger.kernel.org Cc: Nadia Yvette Chambers Cc: Peter Hurley Paul Gortmaker (10): fs: make notify dnotify.c explicitly non-modular fs: make quota/netlink.c explicitly non-modular fs: make fcntl.c explicitly non-modular fs: make filesystems.c explicitly non-modular fs: make locks.c explicitly non-modular fs: make direct-io.c explicitly non-modular fs: make devpts/inode.c explicitly non-modular fs: make binfmt_elf.c explicitly non-modular fs: make hugetlbfs/inode.c explicitly non-modular fs: make quota/dquot.c explicitly non-modular fs/binfmt_elf.c | 11 +---------- fs/devpts/inode.c | 3 +-- fs/direct-io.c | 4 ++-- fs/fcntl.c | 4 +--- fs/filesystems.c | 2 +- fs/hugetlbfs/inode.c | 27 ++------------------------- fs/locks.c | 3 +-- fs/notify/dnotify/dnotify.c | 4 +--- fs/quota/dquot.c | 2 +- fs/quota/netlink.c | 5 +---- 10 files changed, 12 insertions(+), 53 deletions(-) -- 2.6.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/