Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1290465 > unrolled thread

[PATCH 00/10] fs: don't use module_init in non-modular code

Back to article view | Back to linux.kernel

Contents

  [PATCH 00/10] fs: don't use module_init in non-modular code Paul Gortmaker <paul.gortmaker@windriver.com> - 2015-12-12 22:40 +0100
    [PATCH 05/10] fs: make locks.c explicitly non-modular Paul Gortmaker <paul.gortmaker@windriver.com> - 2015-12-12 22:40 +0100
      Re: [PATCH 05/10] fs: make locks.c explicitly non-modular Jeff Layton <jlayton@poochiereds.net> - 2015-12-14 12:40 +0100
        Re: [PATCH 05/10] fs: make locks.c explicitly non-modular Paul Gortmaker <paul.gortmaker@windriver.com> - 2015-12-14 16:40 +0100

#1290465 — [PATCH 00/10] fs: don't use module_init in non-modular code

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 <viro@zeniv.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: David Howells <dhowells@redhat.com>
Cc: Eric Paris <eparis@parisplace.org>
Cc: Jan Kara <jack@suse.com>
Cc: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Jeff Layton <jlayton@poochiereds.net>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: linux-fsdevel@vger.kernel.org
Cc: Nadia Yvette Chambers <nyc@holomorphy.com>
Cc: Peter Hurley <peter@hurleysoftware.com>

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/

[toc] | [next] | [standalone]

#1290466 — [PATCH 05/10] fs: make locks.c explicitly non-modular

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 <jlayton@poochiereds.net>
Cc: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 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)
-- 
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/

[toc] | [prev] | [next] | [standalone]

#1291125 — Re: [PATCH 05/10] fs: make locks.c explicitly non-modular

On Sat, 12 Dec 2015 16:30:07 -0500
Paul Gortmaker <paul.gortmaker@windriver.com> 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 <jlayton@poochiereds.net>
> Cc: "J. Bruce Fields" <bfields@fieldses.org>
> Cc: Alexander Viro <viro@zeniv.linux.org.uk>
> Cc: linux-fsdevel@vger.kernel.org
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
>  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 <jlayton@poochiereds.net>
--
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/

[toc] | [prev] | [next] | [standalone]

#1291284 — Re: [PATCH 05/10] fs: make locks.c explicitly non-modular

[Re: [PATCH 05/10] fs: make locks.c explicitly non-modular] On 14/12/2015 (Mon 06:31) Jeff Layton wrote:

> On Sat, 12 Dec 2015 16:30:07 -0500
> Paul Gortmaker <paul.gortmaker@windriver.com> 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.
> > 

[...]

> 
> 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?

I was hoping to spread as many of these around as possible so I don't
end up with a giant pull request to Linus.  There is code out there
without a clear maintainership path, so eventually I'll have to send
some his way (or via akpm) but the less that end up in that pile, the
better IMHO.

It looks like the hugetlb init level change upset one of the automated
qemu 0-day boot tests, so I need to investigate that next.

Paul.
--

> 
> Acked-by: Jeff Layton <jlayton@poochiereds.net>
--
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/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web