[PATCH v2 0/5] drivers/tty: make more bool drivers explicitly non-modular

[v2: drop dead module code removal from 8250_lpc18xx.c ; instead convert it
 from bool to tristate ; also add ack to hvc_console commit.]

This second set of patches to drivers/tty steps outside of the serial
dir, and an improved auditing finds two more serial drivers pretending
to be modular that really are not.

The reasoning for doing this is the same as the first set[1] of patches
and is largely copied below:

  In the previous merge window, we made changes to allow better
  delineation between modular and non-modular code in commit
  0fd972a7d91d6e15393c449492a04d94c0b89351 ("module: relocate module_init
  from init.h to module.h").  This allows us to now ensure module code
  looks modular and non-modular code does not accidentally look modular
  without suffering build breakage.
  
  Here we target code that is, by nature of their Kconfig settings, only
  available to be built-in, but implicitly presenting itself as being
  possibly modular by way of using modular headers, macros, and functions.
  
  The goal here is to remove that illusion of modularity from these
  drivers, but in a way that leaves the actual runtime unchanged.
  In doing so, we remove code that has never been tested and adds
  no value to the tree.  And we begin the process of expecting a
  level of consistency between the Kconfig of a driver and the code
  that the driver uses.
  
Build tested for allyesconfig on x86_64, and ARM for lpc81xx, and powerpc
for hvc_console and mpsc, layered onto tty/tty-next as a baseline.

Paul.

[1] https://lkml.kernel.org/r/1437530538-5078-1-git-send-email-paul.gortmaker@windriver.com
--

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <redacted>
Cc: Joachim Eastwood <redacted>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-serial@vger.kernel.org

Paul Gortmaker (5):
  drivers/tty: make pty.c slightly more explicitly non-modular
  drivers/tty: make sysrq.c slightly more explicitly non-modular
  drivers/tty: make hvc_console.c explicitly non-modular
  drivers/tty: make serial/mpsc.c driver explicitly non-modular
  drivers/tty: make serial 8250_lpc18xx.c Kconfig a tristate

 drivers/tty/hvc/hvc_console.c   | 18 +-----------------
 drivers/tty/pty.c               |  7 +++++--
 drivers/tty/serial/8250/Kconfig |  2 +-
 drivers/tty/serial/mpsc.c       | 36 +++---------------------------------
 drivers/tty/sysrq.c             |  6 +++++-
 5 files changed, 15 insertions(+), 54 deletions(-)

-- 
2.5.0

The Kconfig currently controlling compilation of this code is:

drivers/tty/hvc/Kconfig:config HVC_DRIVER
drivers/tty/hvc/Kconfig:        bool

...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, even
though someone bothered to comment that the code was not used.

Unlike other changes, this driver binds in w/o using module_init,
so we dont have init ordering concerns with this commit.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <redacted>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Paul Gortmaker <redacted>
---
 drivers/tty/hvc/hvc_console.c | 18 +-----------------
 1 file changed, 1 insertion(+), 17 deletions(-)

diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 4e9c4cc9e1b5..9c30f67c802a 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c

@@ -29,7 +29,7 @@
 #include <linux/kernel.h>
 #include <linux/kthread.h>
 #include <linux/list.h>
-#include <linux/module.h>
+#include <linux/init.h>
 #include <linux/major.h>
 #include <linux/atomic.h>
 #include <linux/sysrq.h>

@@ -1005,19 +1005,3 @@ put_tty:
 out:
 	return err;
 }
-
-/* This isn't particularly necessary due to this being a console driver
- * but it is nice to be thorough.
- */
-static void __exit hvc_exit(void)
-{
-	if (hvc_driver) {
-		kthread_stop(hvc_task);
-
-		tty_unregister_driver(hvc_driver);
-		/* return tty_struct instances allocated in hvc_init(). */
-		put_tty_driver(hvc_driver);
-		unregister_console(&hvc_console);
-	}
-}
-module_exit(hvc_exit);

-- 
2.5.0

[[PATCH v2 0/5] drivers/tty: make more bool drivers explicitly non-modular] On 19/08/2015 (Wed 17:48) Paul Gortmaker wrote:

[v2: drop dead module code removal from 8250_lpc18xx.c ; instead convert it
 from bool to tristate ; also add ack to hvc_console commit.]

This second set of patches to drivers/tty steps outside of the serial
dir, and an improved auditing finds two more serial drivers pretending
to be modular that really are not.

Hi Greg -- wondering if this is still in your to-do queue.  I see the
patches to drivers/char that I sent about the same time made it onto
your char-testing branch but not these onto tty-testing.

The reason I ask is that I've about a 1/2 dozen more similar patches
that showed up once I started auditing non-x86 code.  I don't want to
re-spam you with these along with the new ones, if these are still in
your backlog for processing.

Thanks,
Paul.
--

The reasoning for doing this is the same as the first set[1] of patches
and is largely copied below:

  In the previous merge window, we made changes to allow better
  delineation between modular and non-modular code in commit
  0fd972a7d91d6e15393c449492a04d94c0b89351 ("module: relocate module_init
  from init.h to module.h").  This allows us to now ensure module code
  looks modular and non-modular code does not accidentally look modular
  without suffering build breakage.
  
  Here we target code that is, by nature of their Kconfig settings, only
  available to be built-in, but implicitly presenting itself as being
  possibly modular by way of using modular headers, macros, and functions.
  
  The goal here is to remove that illusion of modularity from these
  drivers, but in a way that leaves the actual runtime unchanged.
  In doing so, we remove code that has never been tested and adds
  no value to the tree.  And we begin the process of expecting a
  level of consistency between the Kconfig of a driver and the code
  that the driver uses.
  
Build tested for allyesconfig on x86_64, and ARM for lpc81xx, and powerpc
for hvc_console and mpsc, layered onto tty/tty-next as a baseline.

Paul.

[1] https://lkml.kernel.org/r/1437530538-5078-1-git-send-email-paul.gortmaker@windriver.com
--

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <redacted>
Cc: Joachim Eastwood <redacted>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-serial@vger.kernel.org

Paul Gortmaker (5):
  drivers/tty: make pty.c slightly more explicitly non-modular
  drivers/tty: make sysrq.c slightly more explicitly non-modular
  drivers/tty: make hvc_console.c explicitly non-modular
  drivers/tty: make serial/mpsc.c driver explicitly non-modular
  drivers/tty: make serial 8250_lpc18xx.c Kconfig a tristate

 drivers/tty/hvc/hvc_console.c   | 18 +-----------------
 drivers/tty/pty.c               |  7 +++++--
 drivers/tty/serial/8250/Kconfig |  2 +-
 drivers/tty/serial/mpsc.c       | 36 +++---------------------------------
 drivers/tty/sysrq.c             |  6 +++++-
 5 files changed, 15 insertions(+), 54 deletions(-)

-- 
2.5.0

On Sat, Sep 26, 2015 at 06:53:47PM -0400, Paul Gortmaker wrote:

[[PATCH v2 0/5] drivers/tty: make more bool drivers explicitly non-modular] On 19/08/2015 (Wed 17:48) Paul Gortmaker wrote:

quoted

[v2: drop dead module code removal from 8250_lpc18xx.c ; instead convert it
 from bool to tristate ; also add ack to hvc_console commit.]

This second set of patches to drivers/tty steps outside of the serial
dir, and an improved auditing finds two more serial drivers pretending
to be modular that really are not.

Hi Greg -- wondering if this is still in your to-do queue.  I see the
patches to drivers/char that I sent about the same time made it onto
your char-testing branch but not these onto tty-testing.

Yes, they are in my queue, haven't caught up with tty patches yet :(

The reason I ask is that I've about a 1/2 dozen more similar patches
that showed up once I started auditing non-x86 code.  I don't want to
re-spam you with these along with the new ones, if these are still in
your backlog for processing.

I can handle resends and other patches just fine, send away!

thanks,

greg k-h