From: "Song Bao Hua (Barry Song)" <song.bao.hua@hisilicon.com>
To: John Hubbard <jhubbard@nvidia.com>,
Randy Dunlap <rdunlap@infradead.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: Linuxarm <linuxarm@huawei.com>,
Ralph Campbell <rcampbell@nvidia.com>,
John Garry <john.garry@huawei.com>
Subject: RE: [PATCH] mm/gup_benchmark: GUP_BENCHMARK depends on DEBUG_FS
Date: Sun, 8 Nov 2020 07:35:50 +0000 [thread overview]
Message-ID: <a7a56afecfd7484cb0cce8e1d51a8242@hisilicon.com> (raw)
In-Reply-To: <28eb72a6-37de-6e60-9127-d1678aac5f5c@nvidia.com>
> -----Original Message-----
> From: John Hubbard [mailto:jhubbard@nvidia.com]
> Sent: Sunday, November 8, 2020 5:56 PM
> To: Randy Dunlap <rdunlap@infradead.org>; Song Bao Hua (Barry Song)
> <song.bao.hua@hisilicon.com>; akpm@linux-foundation.org;
> linux-mm@kvack.org; linux-kernel@vger.kernel.org
> Cc: Linuxarm <linuxarm@huawei.com>; Ralph Campbell
> <rcampbell@nvidia.com>; John Garry <john.garry@huawei.com>
> Subject: Re: [PATCH] mm/gup_benchmark: GUP_BENCHMARK depends on
> DEBUG_FS
>
> On 11/7/20 8:11 PM, Randy Dunlap wrote:
> ...
> > Look at kconfig-language.rst instead.
>
> aha, yes.
>
> >
> > One thing that could be done (and is done in a few places for other reasons)
> is to add
> > a Kconfig comment if DEBUG_FS is not enabled:
> >
> > comment "GUP_TEST needs to have DEBUG_FS enabled"
> > depends on !GUP_TEST && !DEBUG_FS
> >
>
> Sweet--I just applied that here, and it does exactly what I wanted: puts a nice
> clear
> message on the "make menuconfig" screen. No more hidden item. Brilliant!
>
> Let's go with that, shall we?
Do you want this
(Code A)
diff --git a/mm/Kconfig b/mm/Kconfig
index 01b0ae0cd9d3..d80839d1fad8 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -853,6 +853,9 @@ config GUP_TEST
See tools/testing/selftests/vm/gup_test.c
+comment "GUP_TEST needs to have DEBUG_FS enabled"
+ depends on !GUP_TEST && !DEBUG_FS
+
config GUP_GET_PTE_LOW_HIGH
bool
Or do you want this ?
(Code B)
diff --git a/mm/Kconfig b/mm/Kconfig
index 01b0ae0cd9d3..a7ff0d31afd5 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -836,6 +836,7 @@ config PERCPU_STATS
config GUP_TEST
bool "Enable infrastructure for get_user_pages()-related unit tests"
+ depends on DEBUG_FS
help
Provides /sys/kernel/debug/gup_test, which in turn provides a way
to make ioctl calls that can launch kernel-based unit tests for
@@ -853,6 +854,9 @@ config GUP_TEST
See tools/testing/selftests/vm/gup_test.c
+comment "GUP_TEST needs to have DEBUG_FS enabled"
+ depends on !GUP_TEST && !DEBUG_FS
+
config GUP_GET_PTE_LOW_HIGH
bool
To be honest, I am not a big fan of both of code A and B. I think "depends on" has
clearly said everything the redundant comment wants to say.
│ Symbol: GUP_TEST [=]
│ Type : bool
│ Defined at mm/Kconfig:837
│ Prompt: Enable infrastructure for get_user_pages()-related unit tests
│ Depends on: DEBUG_FS [=n]
│ Location:
│ (1) -> Memory Management option
Menuconfig shows GUP_TEST depends on DEBUG_FS and right now DEBUG_FS is
"n". so it is impossible to enable GUP_TEST.
"comment" is a good thing, but it is more likely to be used for a menu or a group
of configurations to extend a bundle of things.
On the other hand, If this particular case needs this comment, so do countless
other configurations in hundreds of Kconfig files.
My favorite order is
1. depends on
2. select
3. depends on + comment(code B)
4. comment only(code A)
I won't accept 4, but it seems we can't get agreement on 1 which is my favorite.
So if you want either one of 2 and 3, I am happy to send v2 for that. So which one
is your favorite? 2 or 3?
>
> thanks,
> --
> John Hubbard
> NVIDIA
Thanks
Barry
next prev parent reply other threads:[~2020-11-08 7:35 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-04 10:05 Barry Song
2020-11-07 0:12 ` John Hubbard
2020-11-07 19:05 ` Song Bao Hua (Barry Song)
2020-11-07 19:16 ` John Hubbard
2020-11-07 22:20 ` Randy Dunlap
2020-11-08 0:03 ` John Hubbard
2020-11-08 0:24 ` Randy Dunlap
2020-11-08 1:10 ` John Hubbard
2020-11-08 2:58 ` Song Bao Hua (Barry Song)
2020-11-08 3:14 ` John Hubbard
2020-11-08 3:22 ` John Hubbard
2020-11-08 4:11 ` Randy Dunlap
2020-11-08 4:34 ` Song Bao Hua (Barry Song)
2020-11-08 4:55 ` John Hubbard
2020-11-08 7:35 ` Song Bao Hua (Barry Song) [this message]
2020-11-08 7:53 ` John Hubbard
2020-11-08 4:05 ` Song Bao Hua (Barry Song)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a7a56afecfd7484cb0cce8e1d51a8242@hisilicon.com \
--to=song.bao.hua@hisilicon.com \
--cc=akpm@linux-foundation.org \
--cc=jhubbard@nvidia.com \
--cc=john.garry@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxarm@huawei.com \
--cc=rcampbell@nvidia.com \
--cc=rdunlap@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox