From: "Huang\, Ying" <ying.huang@intel.com>
To: Michal Hocko <mhocko@suse.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
"Matthew Wilcox \(Oracle\)" <willy@infradead.org>,
Rafael Aquini <aquini@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Ingo Molnar <mingo@redhat.com>, Mel Gorman <mgorman@suse.de>,
Rik van Riel <riel@redhat.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Dave Hansen <dave.hansen@intel.com>,
Andi Kleen <ak@linux.intel.com>,
David Rientjes <rientjes@google.com>
Subject: Re: [PATCH -V2 1/2] mempolicy: Rename MPOL_F_MORON to MPOL_F_MOPRON
Date: Mon, 02 Nov 2020 11:12:59 +0800 [thread overview]
Message-ID: <87d00wxxhg.fsf@yhuang-dev.intel.com> (raw)
In-Reply-To: <20201030082517.GD1478@dhcp22.suse.cz> (Michal Hocko's message of "Fri, 30 Oct 2020 09:25:17 +0100")
Michal Hocko <mhocko@suse.com> writes:
> On Fri 30-10-20 15:27:51, Huang, Ying wrote:
>> Michal Hocko <mhocko@suse.com> writes:
>>
>> > On Wed 28-10-20 10:34:10, Huang Ying wrote:
>> >> To follow code-of-conduct better.
>> >
>> > This is changing a user visible interface and any userspace which refers
>> > to the existing name will fail to compile unless I am missing something.
>>
>> Although these flags are put in uapi, I found these flags are actually
>> internal flags used in "flags" field of struct mempolicy, they are never
>> used as flags for any user space API. I guess they are placed in uapi
>> header file to guarantee they aren't conflict with MPOL_MODE_FLAGS.
>
> You are right. I have missed that. The comment in the header even explains
> that. Anyway the placement is rather unusual and I think that those
> flags do not belong there.
>
>> > Have you checked how many applications would be affected?
>>
>> Based on above analysis, I think there is no application that will be
>> affected.
>>
>> > Btw I find "follow CoC better" a very weak argument without further
>> > explanation.
>>
>> That is the only reason for the patch. If nobody thinks the change is
>> necessary, I can just drop the patch.
>
> Well, to be honest I do not see any problem with the naming.
This is a capitalized words and prefixed, so most people think it's OK.
And in PATCH 2/2, there's a newly added label,
mopron:
Which may become
moron:
some people think that we'd better to change it. And to make the wording
consistent, the constant is changed too.
Best Regards,
Huang, Ying
next prev parent reply other threads:[~2020-11-02 3:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-28 2:34 [PATCH -V2 0/2] autonuma: Migrate on fault among multiple bound nodes Huang Ying
2020-10-28 2:34 ` [PATCH -V2 1/2] mempolicy: Rename MPOL_F_MORON to MPOL_F_MOPRON Huang Ying
2020-10-29 9:04 ` Michal Hocko
2020-10-30 7:27 ` Huang, Ying
2020-10-30 8:25 ` Michal Hocko
2020-11-02 3:12 ` Huang, Ying [this message]
2020-10-28 2:34 ` [PATCH -V2 2/2] autonuma: Migrate on fault among multiple bound nodes Huang Ying
2020-11-02 11:17 ` Mel Gorman
2020-11-04 5:36 ` Huang, Ying
2020-11-05 11:25 ` Mel Gorman
2020-11-06 7:28 ` Huang, Ying
2020-11-06 15:55 ` Ben Widawsky
2020-11-11 6:50 ` Huang, Ying
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=87d00wxxhg.fsf@yhuang-dev.intel.com \
--to=ying.huang@intel.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=aquini@redhat.com \
--cc=dave.hansen@intel.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=rientjes@google.com \
--cc=willy@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.