> An experienced developer would be able to very easily spot that trying > to optimize seq_printf() versus seq_puts() is barely going to be measurable. Would you like to offer any incentives to use a more appropriate function from this Linux programming interface for sequences? > It's the sort of thing that a developer might fix while > making other, more useful changes to a source file. I get doubts when you expect that change possibilities with a higher priority should and will almost always picked up before update candidates with a lower impact. > Well, please note that having a reputation of someone who insists on > sending mostly junk patches (and like junk food, they may have some > nutritive value; but that doesn't change the effect that the net > benefit to person consuming them is marginal or negative), tends to > give you a bad reputation, and may in fact be a hinderance towards > your being able to attain "financial incentives". I can not offer the “shiny gold nugget” or “pure diamond” so far directly which is often preferred. > If that is in fact your goal, I would gently suggest that you spend > more time improving your skills, and learning more about higher-value > ways you could contribute to the kernel, instead of spamming the > kernel list with lots of low value patches. * I could extend my source code search patterns in principle. How many developers and software reviewers struggle with results from existing code analysis tools? * Will your interest occasionally grow for collateral software evolution? > In the future if you are adding higher value improvements, and you want > to do various cleanups, such as fixing up seq_printf -> seq_puts changes, sure. Is this kind of feedback a contradiction at the moment when you seem to give the impression that my software development reputation is so damaged in the “junk food” sense that I could hardly achieve the software change mixture which you would prefer? Regards, Markus
