From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1760748AbcBYOJf (ORCPT <rfc822;w@1wt.eu>);
	Thu, 25 Feb 2016 09:09:35 -0500
Received: from mail113-251.mail.alibaba.com ([205.204.113.251]:60128 "EHLO
	us-alimail-mta2.hst.scl.en.alidc.net" rhost-flags-OK-OK-OK-FAIL)
	by vger.kernel.org with ESMTP id S1760641AbcBYOJe (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 25 Feb 2016 09:09:34 -0500
X-Alimail-AntiSpam: AC=CONTINUE;BC=0.1796832|-1;FP=0|0|0|0|0|-1|-1|-1;HT=e01l07385;MF=chengang@emindsoft.com.cn;NM=1;PH=DS;RN=13;RT=12;SR=0;TI=SMTPD_----4YKOpHM_1456409303;
Message-ID: <56CF0BB6.2040102@emindsoft.com.cn>
Date: Thu, 25 Feb 2016 22:12:06 +0800
From: Chen Gang <chengang@emindsoft.com.cn>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: SeongJae Park <sj38.park@gmail.com>
CC: trivial@kernel.org, akpm@linux-foundation.org, vbabka@suse.cz,
        rientjes@google.com, linux-kernel@vger.kernel.org, mhocko@suse.cz,
        hannes@cmpxchg.org, mgorman@techsingularity.net,
        vdavydov@virtuozzo.com, dan.j.williams@intel.com, linux-mm@kvack.org
Subject: Re: [PATCH trivial] include/linux/gfp.h: Improve the coding styles
References: <1456352791-2363-1-git-send-email-chengang@emindsoft.com.cn> <alpine.DEB.2.10.1602250952030.16296@hxeon>
In-Reply-To: <alpine.DEB.2.10.1602250952030.16296@hxeon>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2/25/16 09:01, SeongJae Park wrote:
> 
> Well, the indentation for the comment and the '\' looks odd to me.  If
> the 80 column limit is necessary, how about moving the comment to above
> line of the macro as below?  Because comments are usually placed before
> the target they are explaining, I believe this may better to read.
> 
>  -#define __GFP_MOVABLE        ((__force gfp_t)___GFP_MOVABLE)  /* ZONE_MOVABLE allowed */
>  +/* ZONE_MOVABLE allowed */
>  +#define __GFP_MOVABLE        ((__force gfp_t)___GFP_MOVABLE)
> 
> Maybe the opinion can be applied to below similar changes, too.
> 

At least for me, what you said above is OK (it is a common way).

And welcome other members' suggestions.

Thanks.
-- 
Chen Gang (陈刚)

Managing Natural Environments is the Duty of Human Beings.