"Ok, it's a bloody large -rc (as was 24-rc1, for that matter), probably because the 2.6.24 release cycle dragged out, so people had a lot of things pending," noted Linus Torvalds, announcing the 2.6.25-rc1 kernel. He added, "the full diff is something like 11MB and 1.4M lines of diffs, with the bulk of the stuff being in architecture updates and drivers." Linus continued:
"Just to have some fun, I did trivial statistics, and of the 1.4M lines of diffs, about 38% - 530k lines - were in architecture files (400k+ lines of diffs in arch/, 100k+ lines of diffs in include/asm-*), and another big chunk is in drivers (including sound) at about 44% - 610k lines - of changes. The rest comes in much smaller, but still noticeable is networking (8% - 110k lines), with filesystems at 4%, and documentation at about 2%. The remaining crumbles being spread out mostly over block layer, crypto, kernel core, and security layer updates (ie SElinux and smack)."
Linus highlighted a few of the changes, including, "the Intel graphics driver is starting to do suspend/resume natively (ie even without X support), which is a welcome sign of the times and may help some people; lots of cleanups from the x86 merge (making more and more use of common files), but also the big page attribute stuff is in and caused a fair amount of churn, and while most of the issues should have been very obvious and all got fixed, this is definitely one of those things that we want a lot of very wide testing of to make sure nothing regressed; fair number of changes to things like the legacy IDE drivers too, and a totally new driver for the very common PCIE version of the Intel e1000 network card etc; and I've probably totally forgotten about tons of other stuff I should have mentioned, but the point is that not only do we have lots of new core, we do have a fair amout of changes to basic stuff that can actually affect perfectly bog-standard hardware setups. So give it all a good testing."
Feature list:
- ... and no kgdb?
Who cares? If you don't know
Who cares?
If you don't know how to apply a patch, you're not able to use a debugger anyway...
out of tree patches break all the time
It's not about applying the patch, it's about making sure it keeps working.
Out of tree patches break all the time. You can hardly rely on them for anything because they always break just when you need to use them.
Changes need of course to be added or rejected based on their merits, but "you can just apply the patch" would be a very weak reason not to merge something.