From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by kanga.kvack.org (Postfix) with ESMTP id B7F626B0253 for ; Tue, 22 Sep 2015 11:20:43 -0400 (EDT) Received: by padhy16 with SMTP id hy16so12102063pad.1 for ; Tue, 22 Sep 2015 08:20:43 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com. [141.146.126.69]) by mx.google.com with ESMTPS id c10si3331829pbu.118.2015.09.22.08.20.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Sep 2015 08:20:42 -0700 (PDT) Date: Tue, 22 Sep 2015 11:20:38 -0400 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH 01/10] mm: make cleancache.c explicitly non-modular Message-ID: <20150922152038.GE4454@l.oracle.com> References: <1440454482-12250-1-git-send-email-paul.gortmaker@windriver.com> <1440454482-12250-2-git-send-email-paul.gortmaker@windriver.com> <20150825011040.GA3560@windriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150825011040.GA3560@windriver.com> Sender: owner-linux-mm@kvack.org List-ID: To: Paul Gortmaker Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org 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 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 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 > > >Cc: linux-mm@kvack.org > > >Signed-off-by: Paul Gortmaker > > >--- > > > 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 > > >+#include > > > #include > > > #include > > > #include > > >@@ -316,4 +316,4 @@ static int __init init_cleancache(void) > > > #endif > > > return 0; > > > } > > >-module_init(init_cleancache) > > >+device_initcall(init_cleancache) > > > > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org