On 2/27/16 10:45, Theodore Ts'o wrote:

On Fri, Feb 26, 2016 at 11:26:02PM +0800, Chen Gang wrote:

quoted

quoted

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.

No, it's been accepted that checkpatch requiring people to reformat
code to within be 80 columns limitation was actively harmful, and it
no longer does that.

Worse, it now complains when you split a printf string across lines,
so there were patches that split a string across multiple lines to
make checkpatch shut up.  And now there are patches that join the
string back together.

And if you now start submitting patches to split them up again because
you think the 80 column restriction is so darned important, that would
be even ***more*** code churn.

I don't think so. Of cause NOT the "CODE CHURN". It is not correct to
make an early decision during discussing.

"80 column limitation" is mentioned in "Documentation/CodingStyle", if
we have very good reason for it, we can break this limitation (for me,
what you said above are really some of good reasons).

But in our case (the patch), can anybody find any "good reasons" for it?
at least, at present, I can not find:

 - It is a common shared base header file, it is almost not used for
   code analyzing (e.g. git diff, git blame).

 - Is it helpful for "grep xxx filename | grep yyy"? Please check the
   patch, I can not find (maybe __GFP_MOVABL definition be? but it is
   still not obvious, if some member stick to, we can keep it no touch).

 - Could anyone find any good reasons for it within this patch?

Which is one of the reasons why some of us aren't terribly happy with
people who start running checkpatch -file on other people's code and
start submitting patches, either through the trivial patch portal or
not.

For me, as a individual developer, I don't like this way, either. So of
cause, I don't care about this way.

I am just reading the common shared header files about mm. At least, I
can understand some common sense of mm, and also read through the whole
other headers to know what they are.

When I find something valuable more or less, I shall send related patch
for it.

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.

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.


Thanks.
-- 
Chen Gang (e??a??)

Managing Natural Environments is the Duty of Human Beings.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>