In the ongoing effort to reduce the power consumption of the linux kernel [story] and take better advantage of the tickless kernel patch [story], Stephen Hemminger posted a patch to make it possible to unload the keyboard blink driver, "the blink driver wakes up every jiffy which wastes power unnecessarily. Using a notifier gives same effect. Also add ability to unload module." The blink driver was only recently merged, described as a "simple driver that blinks the keyboard LEDs when loaded. Useful for checking that the kernel is still alive or for crashdumping."

Linus Torvalds reviewed the driver and retorted, "I really get the feeling this thing should be removed entirely. Wasting power is the _least_ of its problems." When it was pointed out that the driver is only a debugging tool, Linus listed his complaints, "it has been a total disaster from beginning to end. It wastes power. It hangs machines when it tries to blink," going on to add, "its main problem is that PEOPLE SHOULD NOT USE IT, but it sounds cool, so people end up configuring the damn thing even though they shouldn't." Ultimately, Linus removed the driver before the 2.6.22 release [story] noting, "we could have just disabled it, but there's work on a new one that isn't as fundamentally broken, so there really doesn't seem to be any point in keeping it around."

A kernel crash dump is a snapshot of system state taken at the time that the kernel crashed, useful for finding and debugging the problem that caused the crash in the first place. There is no standard mechanism for automatiaclly collecting a crash dump on Linux, but there are a number of existing projects working toward efficiently meeting this goal. A "Linux Kernel Dump Summit" was recently mentioned on the lkml, with participants from some of the many crash dump projects looking to standardize the dump process and information collected. A followup email noted, "as memory size grows, the time and space for capturing kernel crash dumps really matter." It went on to examine partial dumps, and full dumps that are compressed. The former risks not collecting information necessary for proper debugging, while the latter risks greatly increasing the amount of time required to collect a dump.

There are a number of existing projects for collecting automatic kernel crash dumps on Linux, including Linux Kernel Crash Dump (LKCD), Mini Kernel Dump (mkdump), kdump, and diskdump (detailed here). Some of these projects also include tools for examining the obtained dumpfiles. Other projects focus just on tools for analyzing kernel crash dumps, including the perl-based Alicia (the Advanced LInux Crash-dump Interactive Analyzer) and Red Hat's crash analysis tool "loosely based on the SVR4 UNIX crash command, but significantly enhanced by completely merging it with the GNU gdb debugger."

In response to whether or not he had any objections to merging FUSE [story] into the mainline kernel, Andrew Morton [interview] offered some insight into what new features were slated for the upcoming 2.6.12 kernel. Andrew began, "I was planning on sending FUSE onto Linus in a week or two," going on to add "that and cpusets are the notable features which are 2.6.12 candidates."

Andrew then referred to several other patches currently in his -mm patchset [story], discussing their likelihood of being merged into the mainline kernel. He described crashdump [story] as seeming "permanently not-quite-ready". He noted that perfctr "works fine", but that it was "similar-to-but-different-from" the IA64 perfmon subsystem, and "might not be suitable for ppc64". Both nfsacl [thread] and the device-mapper multipath [thread] patches were deemed "OK for 2.6.12". Regarding cachefs, Andrew noted it "is a bit stuck because it's a ton of complex code and afs is the only user of it. Wiring it up to NFS would help." Finally, regarding whether or not he planned to merge reiser4 [story], he said this was "less clear" going on to add "once all the review comments have been addressed and we start seeing a bit of vendor pull for it, maybe."