"I think our mistake is the assumption that everyone who wants to contribute to the kernel wants to code, or that everyone wants to end up at the top of the major feature contributors list. For lots of people, we're going to be that experiment from college they never quite want to admit to later on in life."

"If you can't use strcpy and strlcpy correctly, then you should not be a programmer."

"Look at anyone who is extremely nimble with the kernel, and ask them what they worked on to get going with development. Did Andrew Morton fixup whitespace errors when he was starting to become familiar with the tree? Did I?

"My suggestion to you, and to everyone else who wants to improve the quality of this community, is to become a part of it. Learn a subsystem. Post patches that fix problems people care about. Listen to criticism and respond to it constructively."

"Let's all take a deep breath and relax, ok? A patch was aggressively presented and aggressively NAKed. Let's not get our bowels in an uproar over it. Nothing to see here folks, move along..."

"I do think that if one is already changing a line which is incorrectly laid out then there's no point in _leaving_ it incorrect. There's no downside to fixing it. That being said, it's often sorely tempting to go hunting down nearby sillinesses. I succumb to that temptation and usually won't complain when others do also, up to a point."

"An RTOS (Real-time Operating System) will sacrifice performance to achieve determinism (low latencies). Several key features to an RT system usually come with a performance cost. A non RT system will perform 99% of the time faster than an RTOS. But all it takes is that one time to miss a deadline to make an RT system crash.

"This is the largest performance improvement to hit the RT patch since the removal of the global PI lock. On my 4way box running 'hackbench 50' went from 18 seconds down to just under 5 seconds (4.8). Vanilla 2.6.24.7 on this same box runs at 3.9 secs. This is the first time that the RT patched kernel is less than a magnitude away from mainline running this hackbench test."

"If you're sure that this code doesn't need the BKL (and it kind of looked that way to me), the preferred approach seems to be to put in a comment to that effect so that it's clear that the code has been looked at. So sending me a patch which does this would be great.

"Have you ever been an hour and a half into a bisection at 3AM then hit a massive oops deep in the TCP code which was spread across a large number of commits? I have and it wasn't fun. If I remember correctly I gave up and went to bed."

"This code doesn't get merged. It doesn't get merged before 2.6.26, and it doesn't get merged _after_ either. Rewrite the code, or not. I don't care. I'll very happily not merge crap for the rest of my life."

"I think people are placing too much blame on valgrind. valgrind doesn't tell you 'Delete this line of code.' It says 'You are using uninitialized memory here.' The correct fix is to initialize the memory, not delete the line of code. It's not about trusting or not trusting the tool; it's about responding correctly."

"You really need to realize that reality is messy, and things cannot be pefect. You also need to realize and *understand* that aiming for 'good' is actually much BETTER than trying to aim for 'perfect'. Perfect is the enemy of good."

"I should also add that there's a ton of work that needs to be done in the kernel for BGL removal in general, particularly the I/O paths (the network path being only part of the larger picture). There's plenty of thesis material there, particularly because our cpu-localization approach is very different from the tact that other OS's have taken."

"This is a(nother) case where a toolchain/process problem is forcing us to do something which we don't want to do. In an ideal world we should tell the git developers 'we want x, please' and hopefully they can give it to us. Because right now, we're having to work around shortcomings in git and we are producing a lesser product as a result of this.