linux-kernel - Re: [PATCH 01/10] mm: make cleancache.c explicitly non-modular

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150825011040.GA3560@windriver.com>
Date:	Mon, 24 Aug 2015 21:10:40 -0400
From:	Paul Gortmaker <paul.gortmaker@...driver.com>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
CC:	Andrew Morton <akpm@...ux-foundation.org>, <linux-mm@...ck.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 01/10] mm: make cleancache.c explicitly non-modular

[Re: [PATCH 01/10] mm: make cleancache.c explicitly non-modular] On 24/08/2015 (Mon 20:10) Konrad Rzeszutek Wilk wrote:

> On August 24, 2015 6:14:33 PM EDT, Paul Gortmaker <paul.gortmaker@...driver.com> wrote:
> >The Kconfig currently controlling compilation of this code is:
> >
> >config CLEANCACHE
> >bool "Enable cleancache driver to cache clean pages if tmem is present"
> >
> >...meaning that it currently is not being built as a module by anyone.
> 
> Why not make it a tristate?

Simple.  I'm making the code consistent with its current behaviour.
I'm not looking to extend functionality in code that I don't know
intimately.  I can't do that and do it reliably and guarantee it
works as a module when it has never been used as such before.

I've got about 130 of these and counting.  Some of them have been bool
since before git history ; before the turn of the century.  If there was
demand for them to be tristate, then it would have happened by now.  So
clearly there is no point in looking at making _those_ tristate.

I did have one uart driver author indicate that he _meant_ his code to
be tristate, and he tested it as such, and asked if I would convert it
to tristate on his behalf.  And that was fine and I did exactly that.

But unless there are interested users who want their code tristate and
can vouch that their code works OK as such, I can only make the code
consistent with the implicit non-modular behaviour that the Kconfig and
Makefiles have dictated up to now.  Are there such users for CLEANCACHE?

Paul.
--

> 
> 
> >
> >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 remains unchanged with this commit.
> >
> >Cc: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
> >Cc: linux-mm@...ck.org
> >Signed-off-by: Paul Gortmaker <paul.gortmaker@...driver.com>
> >---
> > mm/cleancache.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> >diff --git a/mm/cleancache.c b/mm/cleancache.c
> >index 8fc50811119b..ee0646d1c2fa 100644
> >--- a/mm/cleancache.c
> >+++ b/mm/cleancache.c
> >@@ -11,7 +11,7 @@
> >  * This work is licensed under the terms of the GNU GPL, version 2.
> >  */
> > 
> >-#include <linux/module.h>
> >+#include <linux/init.h>
> > #include <linux/fs.h>
> > #include <linux/exportfs.h>
> > #include <linux/mm.h>
> >@@ -316,4 +316,4 @@ static int __init init_cleancache(void)
> > #endif
> > 	return 0;
> > }
> >-module_init(init_cleancache)
> >+device_initcall(init_cleancache)
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/