"I lost a day-and-a-half this week due to a disk that decided to get read errors due to an unfortunate power outage, and had to spend too much time regenerating my normal setup," began Linus Torvalds, announcing the 2.6.25-rc6 kernel, "but I don't think I lost any emails, and things seemed to have calmed down a bit, so here's to hoping that -rc6 is starting to look better." He then summarized the changes:
"The dirstat shows the usual pattern of most changes being in drivers and architecture updates, although this time it's a bit skewed by the parisc and powerpc updates (hopefully closing the parisc compile regression among other things), which means that arch is about half, and drivers are just under a third of the patch (it seems to be usually the other way around)."
"The question on the table is [...] whether we should let ndiswrapper continue using GPLONLY symbols. Quite frankly, my position on this has always been that the GPLv2 explicitly covers _derived_ works only, and that very obviously a Windows driver isn't a derived work of the kernel.
"It's a few days late, but I was waiting for some updates for some of the most annoying regressions until releasing it, so the end result is hopefully more useful as a result," Linus Torvalds began, announcing the 2.6.25-rc4 kernel. He offered a dirstat summary, noting, "the dirstat shows that (as usual) most of the changes are in drivers and arch (~51% and ~17% respectively), with about half the driver updates being in network drivers." Linus continued:
"In particular, the block layer changes should hopefully have sorted themselves out, and CD burning etc hopefully works for people again. Same goes for the the scheduler regressions, and a number of annoying boot-time problems. [...] It's really a fair amount of small changes spread all over, with most of the changes being quite small (604 commits, most of them small, with the BNX2X network driver and the new fsldma driver the only ones that got some bigger changes)."
"A change after 2.6.24 broke ndiswrapper by accidentally removing its access to GPL-only symbols," noted Pavel Roskin, offering a patch to address the issue. Linux creator Linus Torvalds was unimpressed, "I'm not seeing why ndiswrapper should be treated separately. If it loads non-GPL modules, it shouldn't be able to use GPLONLY symbols." The NDISwrapper project page explains, "many vendors do not release specifications of the hardware or provide a Linux driver for their wireless network cards. This project implements Windows kernel API and NDIS (Network Driver Interface Specification) API within Linux kernel. A Windows driver for wireless network card is then linked to this implementation so that the driver runs natively, as though it is in Windows, without binary emulation." Due to this, Linus explained:
"Ndiswrapper itself is *not* compatible with the GPL. Trying to claim that ndiswrapper somehow itself is GPL'd even though it then loads modules that aren't is stupid and pointless. Clearly it just re-exports those GPLONLY functions to code that is *not* GPL'd."
"Ok, it's out there, ready for your enjoyment," Linus Torvalds said, announcing the 2.6.25-rc3 kernel. He summarized the changes:
"As usual, most of the updates are in architecture and drivers, with the dirstat showing about 37% in arch (and that's with rename detection: there's some file movement in arch/xtensa that would bring it up to 43% if you looked at it as a traditional diff) and almost 50% in drivers. Much of the include file stuff is also architecture-related updates. The driver updates are mostly fairly spread out, but some of it comes from a couple of new drivers: the mvsas SCSI driver, a new adt7473 driver, and a couple of new watchdog drivers."
Linus continued, "if you ignore the architecture-specific stuff and drivers, the rest is mostly in networking, some Documentation updates, and a few filesystem updates (mainly efs and xfs). Anyway, the upshot of it all? Quite frankly, it's all over the place. The changes in -rc3 are bigger than -rc2, probably mostly because we had some more time (-rc2 was a couple of days early because of the long weekend in the US), but hopefully also because people have started to find regressions." Among the bug fixes, he highlighted, "we had a nasty SLUB corruption issue in -rc2 that is fixed (not that very many people probably saw it), and we've hopfully fixed a number of regressions in networking and suspend/resume."
Issues reported during the suspend-to-disk process lead Linux creator Linus Torvalds to suggest, "please - just make the f*cking suspend-to-disk use other routines already. 99% of all hardware needs to do exactly *nothing* on suspend-to-disk, and the ones that really do need things tend to need to not do a whole lot." He went on to explain why sharing the code path for suspend-to-disk and freezing to RAM is wrong:
"For example, the 'freeze' action for USB (which is one of the hardest things to suspend) should literally be something like just setting the controller STOP bit, and waiting for it to have stopped. The 'unfreeze' should be to just clear the stop bit, while the 'restart' should be just a controller reset to use the current memory image. NONE OF THIS HAS ABSOLUTELY ANYTHING TO DO WITH SUSPEND. It never did. I've told people so for years. Maybe actually seeing the problems will make people realize."
Linus also noted another advantage to having separate code paths for the two actions, "the other issue is that I've long wanted to make sure that when people fix suspend-to-ram, they don't screw up suspend-to-disk by mistake and vice versa." During the discussion, Rafael Wysocki noted that he would be fixing this up presently, "I'm already convinced, really. :-)"
"To quote you a number of years ago: 'Linux is evolution, not intelligent design'," noted Greg KH, quoting Linux creator Linus Torvalds. Linus expanded on the statement, "evolution often does odd (and 'suboptimal') things exactly because it does incremental changes that DO NOT BREAK at any point." He continued, "in other words, exactly *because* evolution requires 'bisectability' (any non-viable point in between is a dead end by definition) and does things incrementally, it doesn't do big flips." When alternative examples in evolution were pointed out, Linus suggested that the kernel was much simpler than a mammal and more similar to bacteria:
"In bacteria (and viruses), duplication of DNA/RNA is a big cost of living in general, and as a result there is *much* less junk DNA. So in an evolutionary sense, it's much closer to what the kernel should have (with occasional duplication of code and interfaces to allow new functionality, but rather aggressive pruning of the excess baggage). In other words, all of these choices are a matter of 'balance'. In some areas, excess code is not a sufficient downside, and we keep even broken source code around with no actual function, 'just because' (or rather, because the cost of carrying it around is so small that nobody cares)."
"Ok, this kernel is a winner," began Linux creator Linus Torvalds, playfully announcing the 2.6.25-rc2 kernel which gained the name "Funky Weasel is Jiggy wit it". He continued:
"Just to show how _much_ of a winner it is, it's been awarded a coveted 'weasel' series name, which should tell you just how good it's going to be. It's a name revered in Linux kernel history, and as such this brings back the good old days where if you find a bug, you're almost certainly simply mistaken, and you probably just did something wrong. But hey, you can try to prove me wrong. I dare you."
Linus went on to describe some of the changes using 'git dirstat', "in particular, it shows that almost exactly half of the updates are to drivers, with network drivers alone being a third of the whole patch. And of the remaining half, about half was architecture updates, notably to SH." He then noted, "I'm optimistic that this release cycle won't be anywhere near the pain of what 24 was, which is why I'm just going to go off for the long weekend and stay at the beach."
"Quite frankly, if kgdb starts doing something 'fancy', there is no way I'll merge it."
"Or, we could just do the ugliest patch ever, namely
-#define pcibus_to_node(node) (-1) +#define pcibus_to_node(node) ((int)(long)(node),-1)
Wow. It's so ugly it's almost wraps around and comes out the other side and looks pretty."
"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."
"You can play games in user space, but you're fooling yourself if you think you can do as well as doing it in the kernel. And you're *definitely* fooling yourself if you think mmap() solves performance issues. 'Zero-copy' does not equate to 'fast'. Memory speeds may be slower than core CPU speeds, but not infinitely so!"
It was recently pointed out that most of the x86 architecture patches had been merged into the mainline 2.6.25 kernel, except for the kgdb patches. Linus Torvalds replied, "I won't even consider pulling it unless it's offered as a separate tree, not mixed up with other things. At that point I can give a look." He continued:
"That said, I explained to Ingo why I'm not particularly interested in it. I don't think that 'developer-centric' debugging is really even remotely our problem, and that I'm personally a lot more interested in infrastructure that helps normal users give better bug-reports. And kgdb isn't even _remotely_ it.
"So I'd merge a patch that puts oops information (or the whole console printout) in the Intel management stuff in a heartbeat. That code is likely much grottier than any kgdb thing will ever be (Intel really screwed up the interface and made it some insane XML thing), but it's also fundamentally more important - if it means that normal users can give oops reports after they happened in X (or, these days, probably more commonly during suspend/resume) and the machine just died."
"The latest feature release GIT 1.5.4 is available at the usual places," began Git maintainer Junio Hamano. He continued, "it has been an unusually long cycle. 5 months since the last feature release 1.5.3 was really a bit too long. But I hope it was worth waiting for. Thanks everybody for working hard to improve it." He noted that there were 165 contributers resulting in 684 changed files, included 70,435 insertions and 28,984 deletions.
The Git distributed version control system was originally written by Linus Torvalds in April of 2005 to temporarily replace BitKeeper, which he had been using to manage kernel source code since February of 2002. Junio Hamano took over maintainership of Git a few months later, in July of 2005, and the tool has long since become quite popular outside of even Linux kernel development. Regarding the latest stable release, Junio highlighted some of the changes, including:
"Comes with much improved gitk, with i18n; comes with git-gui 0.9.2 with i18n; progress displays from many commands are a lot nicer to the eye; rename detection of diff family while detecting exact matches has been greatly optimized; 'git diff' sometimes did not quote paths with funny characters properly; various Perforce importer updates; 'git clean' has been rewritten in C; 'git push' learned --dry-run option to show what would happen if a push is run; 'cvs' is recognized as a synonym for 'git cvsserver', so that CVS users can be switched to git just by changing their login shell; 'git add -i' UI has been colorized; 'git commit' has been rewritten in C; 'git bisect' learned 'skip' action to mark untestable commits; 'git svn' wasted way too much disk to record revision mappings between svn and git, a new representation that is much more compact for this information has been introduced to correct this; in addition there are quite a few internal clean-ups."
Prefacing a series of 196 patches, Greg KH noted, "due to the low level nature of these patches, and because they touch so many different parts of the kernel, a number of the subsystem maintainers have asked me to get them in first to make merging other trees easier." Linus Torvalds agreed and quickly merged the patches into his tree. Greg summarized the many changes:
"They can be broken down into these major areas: Documentation updates (language translations and fixes, as well as kobject and kset documentation updates.); major kset/kobject/ktype rework and fixes; struct bus_type has been reworked to now handle the lifetime rules properly, as the kobject is properly dynamic; struct driver has also been reworked, and now the lifetime issues are resolved; the block subsystem has been converted to use struct device now, and not 'raw' kobjects; nozomi driver is added; lots of class_device conversions to use struct device instead."