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 22:57:36 +0800
From:	Chen Gang <chengang@...ndsoft.com.cn>
To:	Jiri Kosina <jikos@...nel.org>
CC:	Mel Gorman <mgorman@...hsingularity.net>,
	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/26/16 06:39, Jiri Kosina wrote:
> On Fri, 26 Feb 2016, Chen Gang 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.
> 
> You are mistaken here. It's very helpful when debugging;

For me, 'debugging' is related with debugger (e.g. kdb or kgdb), and
'tracing' is related with dumping log, and code analyzing is related
with "git diff" and "git blame".

And yes, for me, "git diff" and "git blame" is really very helpful for
code analyzing.

>                                                         usually you want 
> to find the commit that introduced particular change, and read its 
> changelog (at least). Having to cross rather pointless changes just adds 
> time (need to restart git-blame with commit~1 as a base) for no really 
> good reason.
> 

That is the reason why I am not quite care about body files, I often use
"git log -p filename", the cleanup code patch has negative effect with
code analyzing (although for me, it should still need to be cleanup).

But in our case, it is for the shared header file:

 - They are often the common base file, the main contents will not be
   changed quite often, and their contents are usually simple enough (
   e.g. gfp.h in our case), they are not often for "code analyzing".

 - But they are quite often read in normal reading ways by programmers
   (e.g. open with normal editors). For normal reading, programmers
   usually care about the contents, not the changes.

 - So for me, the common shared header files need always take care about
   coding styles, and need not consider about code analyzing.

And if we reject this kind of patch (in our case), I guess, that almost
mean: "for the common shared header files, their bad coding styles will
be remain for ever".

Thanks.
-- 
Chen Gang (陈刚)

Managing Natural Environments is the Duty of Human Beings.