"I'm a bit behind after investigating the TCP performance issues that turned out to be HW specific problems. It's a bit of a disappointment, I thought maybe there was a cool bug to fix in TCP :-)" explained David Miller, posting his networking merge plans for the upcoming 2.6.24 kernel. He noted, "I merged in Jeff Garzik's and John Linville's latest and I'm running the current tree on my workstation most of today with good results so far." David added, "I plan to commit my Neptune driver in it's current state, and that's the last new feature going in."

In an earlier discussion last month on the Linux netdev mailing list, David described how many changes were in his net-2.6.24 git tree, "it's to the point where every single bug fix put into Linus's tree creates a merge conflict with net-2.6.24, we are simply touching that much stuff. :-)" He added, "we've touched so much in net-2.6.24 that we really should be auditing the thing and fixing any bugs that have been added. If you're bored and looking for something to do, pick an odd NAPI driver and audit it in the net-2.6.24 tree."

"It doesn't seem to pull any dependency nor affect any other external piece of code unless I'm missing something, so it's a perfect example of what we've been discussing back then: there is just no point not merging it at any time right ? :-)" Benjamin Herrenschmidt summarized his request that the iwl4965 driver be merged into the 2.6.23 kernel late in the release cycle, outside of the standard two week merge window. John Linville answered, "it is queued for 2.6.24. I'm not even sure it was originally posted in time for the 2.6.23 merge window, but even if it was there was a lot of opposition to merging it until fairly recently. In fact, I'm sure there are still some wireless developers that are less than happy about merging it now." When asked what the opposition was about, he referred to a discussion on the netdev mailing list and explained:

"There have been a lot of spats about how functionality has been partitioned between the driver and the firmware, issues with how the driver tries to do things that either ought to be in mac80211 or not done at all, and some random complaints about ugliness like '#include "../../../net/mac80211/blah.h"', etc. There is still plenty of work to be done on this driver, but as you point out we are better-off with it in the kernel than with it out."