[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56CF1202.2020809@emindsoft.com.cn>
Date: Thu, 25 Feb 2016 22:38:58 +0800
From: Chen Gang <chengang@...ndsoft.com.cn>
To: Mel Gorman <mgorman@...hsingularity.net>
CC: trivial@...nel.org, akpm@...ux-foundation.org, vbabka@...e.cz,
rientjes@...gle.com, linux-kernel@...r.kernel.org, mhocko@...e.cz,
hannes@...xchg.org, vdavydov@...tuozzo.com,
dan.j.williams@...el.com, linux-mm@...ck.org,
Chen Gang <gang.chen.5i5j@...il.com>
Subject: Re: [PATCH trivial] include/linux/gfp.h: Improve the coding styles
On 2/25/16 17:27, Mel Gorman wrote:
> On Thu, Feb 25, 2016 at 06:26:31AM +0800, chengang@...ndsoft.com.cn wrote:
>> From: Chen Gang <chengang@...ndsoft.com.cn>
>>
>> Always notice about 80 columns, and the white space near '|'.
>>
>> Let the wrapped function parameters align as the same styles.
>>
>> Remove redundant statement "enum zone_type z;" in function gfp_zone.
>>
>> Signed-off-by: Chen Gang <gang.chen.5i5j@...il.com>
>
> NAK from me at least. From my perspective, it's preferrable to preserve
> blame than go through a layer of cleanup when looking for the commit
> that defined particular flags. It's ok to cleanup code at the same time
> definitions change for functional or performance reasons.
>
I can understand for your NAK, it is a trivial patch. For me, I guess
trivial@...nel.org will care about this kind of patch.
If we have another better way than sending trivial patch, that will be
OK to me. At present, I am learning mm in my free time, when I feel
something is valuable more or less, I will send related patch for it.
And excuse me, I guess my english is not quite well, I am not quite
understand the meaning below, could you provide more details?
"it's preferable to preserve blame than go through a layer of cleanup
when looking for the commit that defined particular flags".
Thanks.
--
Chen Gang (陈刚)
Managing Natural Environments is the Duty of Human Beings.
Powered by blists - more mailing lists