linux-kernel - Re: [PATCH trivial] include/linux/gfp.h: Improve the coding styles

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 26 Feb 2016 23:26:02 +0800
From:	Chen Gang <chengang@...ndsoft.com.cn>
To:	Jianyu Zhan <nasa4836@...il.com>
CC:	Mel Gorman <mgorman@...hsingularity.net>, trivial@...nel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Vlastimil Babka <vbabka@...e.cz>, rientjes@...gle.com,
	LKML <linux-kernel@...r.kernel.org>,
	Michal Hocko <mhocko@...e.cz>,
	Johannes Weiner <hannes@...xchg.org>, vdavydov@...tuozzo.com,
	Dan Williams <dan.j.williams@...el.com>,
	"linux-mm@...ck.org" <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/26/16 10:32, Jianyu Zhan wrote:
> On Fri, Feb 26, 2016 at 6:29 AM, Chen Gang <chengang@...ndsoft.com.cn> wrote:
>> git is a tool mainly for analyzing code, but not mainly for normal
>> reading main code.
>>
>> So for me, the coding styles need not consider about git.
> 
> For you, maybe yes.
> 
> But for most of the developers/learners,  git blame does help a lot.
> Kernel code was not as complicated as it is now, it is keeping evolving.
> 

Yes.

> So basically a history chain is indispensable in studying such a complex system.
> git blame fits in this role.  I benefited a lot from using it when I
> started to learn the code,
> And,  a pure coding style fix is sometimes really troublesome as I
> have to use git blame
> to go another step up along the history chain,  which is time
> consuming and boring.
> 
> But after all, I bet you will be fond of using it if you dive deeper
> into the kernel code studying.
> And if you do,  you will know why so many developers in this thread
> are so upset and allergic
> to such coding-style fix.
> 

For me, for discussion, I don't care about "so many developers", I only
focus on the proof and the contribution.


> As for coding style, actually IMHO this patch is even _not_ a coding
> style, more like a code shuffle, indeed.
> 

"80 column limitation" is about coding style, I guess, all of us agree
with it.

> And for your commit history, I found actually you have already
> contributed some quit good patches.

For me, I don't care about my history -- except some members find issues
related with my original patches, I have duty to analyze the related
issues together with the finders.

> I don't think it is helpful for a non-layman contributor to keep
> generating such code churn.
> 

For me, we are discussing, so it is not quite suitable to make an early
conclusion (code churn).

For me, I don't care about layman or non-layman, I only focus on the
proof and the contribution.

Thanks.
-- 
Chen Gang (陈刚)

Managing Natural Environments is the Duty of Human Beings.