On Mon, Aug 24, 2015 at 09:10:40PM -0400, Paul Gortmaker wrote: > [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.gortma...@windriver.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?
Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> Sorry for taking so long. It really cannot be tri-state (I tried making it an module) as the cleancache hooks are tied in the mm/filemap.c. > > 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.w...@oracle.com> > > >Cc: linux...@kvack.org > > >Signed-off-by: Paul Gortmaker <paul.gortma...@windriver.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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
