From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932331AbbLNLbN (ORCPT ); Mon, 14 Dec 2015 06:31:13 -0500 Received: from mail-qg0-f54.google.com ([209.85.192.54]:33153 "EHLO mail-qg0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932206AbbLNLbL (ORCPT ); Mon, 14 Dec 2015 06:31:11 -0500 Date: Mon, 14 Dec 2015 06:31:05 -0500 From: Jeff Layton To: Paul Gortmaker , Alexander Viro Cc: , "J. Bruce Fields" , Subject: Re: [PATCH 05/10] fs: make locks.c explicitly non-modular Message-ID: <20151214063105.2b4b624a@tlielax.poochiereds.net> In-Reply-To: <1449955812-10149-6-git-send-email-paul.gortmaker@windriver.com> References: <1449955812-10149-1-git-send-email-paul.gortmaker@windriver.com> <1449955812-10149-6-git-send-email-paul.gortmaker@windriver.com> X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 12 Dec 2015 16:30:07 -0500 Paul Gortmaker wrote: > The Kconfig currently controlling compilation of this code is: > > config FILE_LOCKING > bool "Enable POSIX file locking API" if EXPERT > > ...meaning that it currently is not being built as a module by anyone. > > Lets remove the couple traces of modularity 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 init ordering gets bumped to one level earlier when we > use the more appropriate fs_initcall here. However we've made similar > changes before without any fallout and none is expected here either. > > Cc: Jeff Layton > Cc: "J. Bruce Fields" > Cc: Alexander Viro > Cc: linux-fsdevel@vger.kernel.org > Signed-off-by: Paul Gortmaker > --- > fs/locks.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/fs/locks.c b/fs/locks.c > index fa76eb2910a9..15e2b60aa2d1 100644 > --- a/fs/locks.c > +++ b/fs/locks.c > @@ -119,7 +119,6 @@ > #include > #include > #include > -#include > #include > #include > #include > @@ -2702,7 +2701,7 @@ static int __init proc_locks_init(void) > proc_create("locks", 0, NULL, &proc_locks_operations); > return 0; > } > -module_init(proc_locks_init); > +fs_initcall(proc_locks_init); > #endif > > static int __init filelock_init(void) Looks fine to me and I doubt we'll see any merge conflicts with anything I have queued so far. Do you need any of us to pick any of these up or are you going to be merging them as a set? Acked-by: Jeff Layton