On 07/08/2013 10:26 PM, Paul Gortmaker wrote: > [[PATCH] kernel/smp.c: free related resources when failure occurs in > hotplug_cfd()] On 08/07/2013 (Mon 16:50) Chen Gang wrote: > >> > When failure occurs in hotplug_cfd(), need release related resources, >> > or will cause memory leak. >> > >> > Also beautify the related code. > No. Please do not mix real fixes with trivial whitespace changes. > It makes it harder for the reviewer to find the actual fix, and it > makes the fix less portable to other releases (i.e. stable trees.) >
OH, at least, need delete white spaces. > Also, you say "beautify", but that is a matter of opinion. You > shuffle around the tabs in your whitespace change, and yet even > then you don't manage to adapt it to the general coding style of > having multi-line args align with where the 1st arg starts. So > you have done nothing but pollute the "git blame" history of that > file for other users. > OK, I will send patch v2 for it (which will remove the waste 'beautifying' operation). > You might want to slow down on the quantity of patches you send, > and spend more time reading the comments from other people on > reviewed patches and learning some of the implicit requirements > from those. No, that only means I still need improving my patch sending. Hmm... for 'learning', I think: "learn with each other, never too old to learn, never stop learning", so we can learn from most of patches or replies which sent by many members. e.g. I understand that for beautifying code, I need more consideration: not only about coding style rules, but also the readers from 'git' and the reviewers from 'diff'. > I've noticed that you are already dangerously close > to annoying several key subsystem maintainers, and that is not > the right long term approach to working with the linux community. If no reply, I will(of cause) no reply either. Especially, every members' time resource is always expensive. Thanks. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/