On Sat, 12 Dec 2015 16:30:07 -0500 Paul Gortmaker <[email protected]> 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 <[email protected]> > Cc: "J. Bruce Fields" <[email protected]> > Cc: Alexander Viro <[email protected]> > Cc: [email protected] > Signed-off-by: Paul Gortmaker <[email protected]> > --- > 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 <linux/fdtable.h> > #include <linux/fs.h> > #include <linux/init.h> > -#include <linux/module.h> > #include <linux/security.h> > #include <linux/slab.h> > #include <linux/syscalls.h> > @@ -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 <[email protected]> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
