Hi Dave, > > When it comes to function declaration and function calls, the style in > > mm/memory.c is mixed. We can start counting, but for both other > > multi-line cases it seems that tab-only indentation is predominant. > > Fair enough. > > But you know what the real issue is? > > I have told the bluetooth folks this matters to me, repeatedly. > > And then when I pushback when some unacceptable changes slip through, > they put a bullseye on my head and say I'm being unreasonable. > > What's unreasonable about a maintainer telling you multiple times > to do things a certain way and then getting mad when you still > don't listen? I have no problem in getting these fixed and you actually imposing this coding style on all networking subsystem. That is your prerogative. However I do have a problem if this is not documented in CodingStyle or somewhere else as part of the kernel source. It should be documented and people pointing out the lack of this are full in their right to do so. I personally would expect the maintainer enforcing this rule to ensure that it is properly documented. Especially after such a confusion has arisen. That checkpatch.pl needs an extra command line called --subjective or -strict to have this easily tested is really not intuitive. I would love to see the idea realized that checkpatch.pl does the enabling/disabling of coding style warnings automatically based on the path. Anyway, these are my view points on this. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
