[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56D2439B.2060803@emindsoft.com.cn>
Date: Sun, 28 Feb 2016 08:47:23 +0800
From: Chen Gang <chengang@...ndsoft.com.cn>
To: Jiri Kosina <jikos@...nel.org>
CC: Theodore Ts'o <tytso@....edu>, Jianyu Zhan <nasa4836@...il.com>,
Mel Gorman <mgorman@...hsingularity.net>,
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/28/16 07:14, Jiri Kosina wrote:
> On Sat, 27 Feb 2016, Chen Gang wrote:
>
>>> Mel, as an MM developer, has already NACK'ed the patch, which means
>>> you should not send the patch to **any** upstream maintainer for
>>> inclusion.
>>
>> I don't think I "should not ...". I only care about correctness and
>> contribution, I don't care about any members ideas and their thinking.
>> When we have different ideas or thinking, we need discuss.
>
> If by "discuss" you mean "30+ email thread about where to put a line
> break", please drop me from CC next time this discussion is going to
> happen. Thanks.
>
Excuse me, when I sent this patch, I did not know who I shall send to, I
have to reference to "./scripts/get_maintainer.pl".
If any members have no time to care about it (every members' time are
really expensive), please let me know (can reply directly).
Thanks.
>> For common shared header files, for me, we should really take more care
>> about the coding styles.
>>
>> - If the common shared header files don't care about the coding styles,
>> I guess any body files will have much more excuses for "do not care
>> about coding styles".
>>
>> - That means our kernel whole source files need not care about coding
>> styles at all!!
>>
>> - It is really really VERY BAD!!
>>
>> If someone only dislike me to send the related patches, I suggest: Let
>> another member(s) "run checkpatch -file" on the whole "./include" sub-
>> directory, and fix all coding styles issues.
>
> Which is exactly what you shouldn't do.
>
For me, I also guess, I am not the suitable member to do that (in fact,
I dislike to do like that - "run checkpath -file" on "./include").
> The ultimate goal of the Linux kernel is not 100% strict complicance to
> the CodingStyle document no matter what. The ultimate goal is to have a
> kernel that is under control. By polluting git blame, you are taking on
> aspect of the "under control" away.
>
Yes, the ultimate goal of CodingStyle is to have a kernel that is under
control.
For me, most of files in "./include" are common, simple, and shared
files, which are not quite related with code analyzing (e.g. git log -p,
or git blame), but they are read by others in most times. Is it correct?
> Common sense needs to be used; horribly terrible coding style needs to be
> fixed, sure. Is 82-characters long line horribly terrible coding style?
> No, it's not.
>
For me, what you said above have effect on body files (in kernel, at
least, more than 95% source files are body files, I guess).
But in "./include", most of files are the interface inside and outside
of our kernel, we need take more care about their coding styles.
I often use vertical split window in vim in full screen mode to reading
source code, when I read c source files, I often split window vertically
for the related header files as reference.
Thanks.
--
Chen Gang (陈刚)
Managing Natural Environments is the Duty of Human Beings.
Powered by blists - more mailing lists