"Various other artists think they have the One True Solution and I got tired of arguing, so I thought I would just make it available in my tree and when folks realize they need it they know where to get it."
"Google Summer of Code 2008 is on! Over the past three years, the program has brought together over 1500 students and 2000 mentors from 90 countries worldwide, all for the love of code. We look forward to welcoming more new contributors and projects this year," begins a page listing all the projects planning to participate in this year's GSoC. Among the numerous planned participtants there are many kernel projects, including DragonFly BSD, FreeBSD, Git, GNU/Hurd, Linux, Minix, and NetBSD.
Student applications for GSoC projects begin today, running through the end of the month. Read on for many of the participation announcements from the above projects. For more information about the GSoC, the program's FAQ explains:
"Google Summer of Code (GSoC) is a program that offers student developers stipends to write code for various open source projects. Google will be working with a several open source, free software, and technology-related groups to identify and fund several projects over a three month period. Historically, the program has brought together over 1,500 students with over 130 open source projects to create millions of lines of code. The program, which kicked off in 2005, is now in its fourth year."
"Apparmor can go play with itself. The proper fix is to lift the LSM nonsense into callers and leave vfs_...() alone."
"Allocations of larger pages are not reliable in Linux. If larger pages have to be allocated then one faces various choices of allowing graceful fallback or using vmalloc with a performance penalty due to the use of a page table," began Christoph Lameter, describing the third version of his virtual compound page support patchset. He continued, "a virtual compound allocation means that there will be first of all an attempt to satisfy the request with physically contiguous memory. If that is not possible then a virtually contiguous memory will be created." Christopher proposed two advantages:
"1. Current uses of vmalloc can be converted to allocate virtual compounds instead. In most cases physically contiguous memory can be used which avoids the vmalloc performance penalty. 2. Uses of higher order allocations (stacks, buffers etc) can be converted to use virtual compounds instead. Physically contiguous memory will still be used for those higher order allocs in general but the system can degrade to the use of vmalloc should memory become heavily fragmented."
"There was some hard system failure, and system hardware and operating system keepers needed a few hours to get that level sorted out. Then we have slowly enabled email subsystems one at the time to verify correct operation. Back to enjoying the flood :-)"
"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."
"Wow, does this actually work? If so, I'll apply it no problems..."
"Nvidia needs to fix their code. If this is a burden, perhaps they should publish their code under a GPLv2-compatible license so we can show them how to do it."
"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."
"`tmp' is an awful identifier, and renaming it to `temp' hardly improves it."
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. :-)"
"Not everyone has a mouse and a joystick attached to the computers he builds kernels for..."