"Another week, another -rc," began Linux creator Linus Torvalds, announcing the 2.6.26-rc7 Linux kernel, "and as usual, it's mainly drivers and arch updates - over 90% of changes are in one or the other." He continued:

"A big part of it (about two thirds of the driver update, in fact) is a late-dropping AGP/DRM update that adds support for some new Intel and ATI graphics cards. And a big part of the arch update is the inevitable def_config updates, of course. I'm not all that happy about the timing of the support for the new cards, but at the same time I also hate delaying new drivers. Obviously the hope is that it can't cause any regressions, since the added code is almost entirely for stuff that simply wasn't supported at all before."

Linus concluded, "if you ignore the driver and arch updates, the rest is pretty minor. About half is in networking, and half of the remaining is filesystems updates (mainly ocfs2). And random smatterings elsewhere, like some scheduler updates."

"Slow servers, Skipping audio, Jerky video --everyone knows the symptoms of latency. But to know what's really going on in the system, what's causing the latency, and how to fix it... those are difficult questions without good answers right now," began Arjan van de Van, announcing version 0.1 of LatencyTop, "a tool for developers to visualize system latencies." He continued:

"LatencyTOP is a Linux tool for software developers (both kernel and userspace), aimed at identifying where system latency occurs, and what kind of operation/action is causing the latency to happen. By identifying this, developers can then change the code to avoid the worst latency hiccups.

"There are many types and causes of latency, and LatencyTOP focus on type that causes audio skipping and desktop stutters. Specifically, LatencyTOP focuses on the cases where the applications want to run and execute useful code, but there's some resource that's not currently available (and the kernel then blocks the process). This is done both on a system level and on a per process level, so that you can see what's happening to the system, and which process is suffering and/or causing the delays."

"This patch corrects what I hope are invalid assumptions about the DMA engine layer: Not only Intel(R) hardware can do DMA, and DMA can be used for other things than memcpy and RAID offloading," Haavard Skinnemoen noted, submitted a small patch against the DMADEVICES Kconfig option. He added, "Don't get me wrong; I think Intel deserves lots of respect for creating this framework. But this is also why I got a bit disappointed when I discovered that it seems to be less generic than I initially hoped." Haavard continued:

"DMA controllers, which may support plain memcpy acceleration in addition to more traditional 'slave DMA', are very common in SoC devices, and I think Linux needs a common framework for it. The existing DMA Engine framework seems to come pretty close already, but I think it needs more input from the embedded crowd before it can be completely usable on a large number of embedded systems."

"The Manageability Engine Interface (aka HECI) allows applications to communicate with the Intel(R) Manageability Engine (ME) firmware. It is meant to be used by user-space manageability applications to access ME features such as Intel(R) Active Management Technology, Intel(R) Quiet System Technology and ASF," Anas Nashif began, describing a new driver for accessing services found in most recent Intel desktop chipsets. Andrew Morton offered an initial review of the patch and asked for additional information, "why do we want to include this code in Linux? What value has it to our users, etc? Basically: tell us more stuff.". Anas added:

"The core hardware architecture of Intel Active Management Technology (Intel AMT) is resident in firmware. The micro-controller within the chipset's graphics and memory controller (MCH) hub houses the Management Engine (ME) firmware, which implements various services on behalf of management applications. Additionally, flash memory houses system BIOS, code used by the management engine, and a third-party data store (3PDS) that enables applications to store information as needed in non-volatile memory."

"Intel's Open Source Technology Center is pleased to announce the LessWatts.org project, an open source project for saving power on Linux," began an email posted to the lkml by Arjan van de Ven. The announcement continued:

"LessWatts.org is a place to bring users, developers and distribution makers together around power reduction for linux machines, from mobile to desktop to server to datacenter. LessWatts.org is about a system-level approach to power savings, from the lowest level device drivers in the kernel to the most advanced desktop applications. LessWatts.org is about things you can do to reduce power usage. LessWatts.org is about longer battery life, a lower airconditioning bill, about reducing the impact of computers on the environment."

The announcement went on to note, "at this time of launching the LessWatts.org project, the technology development projects are those that Intel has started, is involved in or has just started working on, such as PowerTOP, Tickless Idle, Graphics and various link power management techniques. We'd like to invite all developers and projects that focus on power saving to join the LessWatts.org effort and community."

Theo de Raadt [interview] described an active effort by OpenBSD developers to work around "serious bugs in Intel's Core 2 cpu". He went on to explain, "these processors are buggy as hell, and some of these bugs don't just cause development/debugging problems, but will *ASSUREDLY* be exploitable from userland code. As is typical, BIOS vendors will be very late providing workarounds / fixes for these processors bugs. Some bugs are unfixable and cannot be worked around. Intel only provides detailed fixes to BIOS vendors and large operating system groups. Open Source operating systems are largely left in the cold." He provided a link to the full errata (in PDF format) as well as a graphical overview, summarizing:

"Note that some errata like AI65, AI79, AI43, AI39, AI90, AI99 scare the hell out of us. Some of these are things that cannot be fixed in running code, and some are things that every operating system will do until about mid-2008, because that is how the MMU has always been managed on all generations of Intel/AMD/whoeverelse hardware. Now Intel is telling people to manage the MMU's TLB flushes in a new and different way. Yet even if we do so, some of the errata listed are unaffected by doing so.

As I said before, hiding in this list are 20-30 bugs that cannot be worked around by operating systems, and will be potentially exploitable. I would bet a lot of money that at least 2-3 of them are."

"ANY rule which reduces your rights is unacceptable," explained Theo de Raadt [interview] in a brief discussion on the OpenBSD -misc mailing list, "especially when the full consequences of such a set of rules may be unclear -- which it always is." The comment was in response to a query about why Intel's firmware was considered non-free. Theo went on to explain:

"Normal free software has no 'contract law' issues, because it is simply given away under 'copyright law with almost all author's rights revoked'. Contract law works differently, because it is based more on the principle of 'you got something, now you have to give something back'. The minute you see a URL like that explaining things in such a way, you should realize that the addition of 'rules' means you are in a different legal system.

"Copyright has no way to apply such rules, therefore [the Intel firmware] is not free."

Keith Packard announced the availability of drivers for Intel's 965GM Express Chipset. Jeff Garzik responded, "great news. Here's hoping that Intel produces a standalone video card eventually, to further take away market share from closed source competitors." In Keith's announcement he explained:

"The Intel® 965GM Express Chipset represents the first mobile product that implements fourth generation Intel graphics architecture. Designed to support advanced rendering features in modern graphics APIs, this chipset includes support for programmable vertex, geometry, and fragment shaders.

"Extending Intel's commitment to work with the X.org and Mesa communities to continuously improve and enhance the drivers, support for this new chipset is provided through the X.org 2.0 Intel driver and the Mesa 6.5.3 releases. These drivers represent significant work by both Intel and the broader open source community."

James Ketrenos announced a new 80211 based driver for the Intel PRO/Wireless 3945ABG network connection adapter, "this new driver uses the new d80211 subsystem previously only available as part of the wireless-dev tree." An earlier incarnation of the driver code was much criticized for its inclusion of a userland binary-only daemon [story], prompting the OpenBSD project to create their own blob-free driver for the card [story]. "The [new] iwlwifi driver for the 3945 does not require the user space daemon, but does require a new microcode image," James explained, "over the past year we were able to make the necessary changes to the microcode used with the 3945 such that we were able to remove the regulatory daemon."

When the question was asked if the driver was going to be pushed for inclusion into the mainline kernel it was noted, "hmmm...I think we need to spend a cycle or so in -mm. 2.6.22 seems more likely for mainline." Pavel Roskin suggested, "iwlwifi is surprisingly good for a just announced driver. It worked for me from the first attempt, and that's the first d80211 driver to do so. In my opinion, it should go to wireless-dev as soon as possible so it can go to -mm together with other drivers."

Damien Bergamini [interview] started a thread on the OpenBSD -misc mailing list in which he summarized Intel's policy toward open-source software being to "make us look like we're open-source friendly by opening a project on sourceforge," and, "give the open-source community the bare minimum so that they can serve as our beta-testers." Damien released a reverse engineered blob-free driver for an Intel wireless chipset earlier this year [story], but work is slow as Intel does not freely provide documentation to the chipset. OpenBSD's battle with Intel has been ongoing for some time [story] leading project creator Theo de Raadt [interview] to say, "before we ask a vendor, we have already lost (ie. the device does not work). When a vendor says no, we have lost nothing further -- there is no way we can lose further than having the device not work. We can only win, and then the device works. So there is no point in giving up until we win back the rights to write software for the hardware that we have purchased." As before, the goal is to get Intel to provide a freely distributable binary firmware.

Theo pointed out that when the open source community works together they can help improve the situation, "in the past, our users have shown that they can help us convince vendors to do the right thing. They have shown vendors the path towards freeing up many pieces of documentation or granting firmware distribution rights. This has helped with many vendors, most of them quite large." He explained that until Intel releases their firmware freely and without restrictions that they are not open source friendly as they claim, "by withholding, Intel is being an Open Source fraud." He went on to suggest that Intel should follow the example of other companies in the market, "Intel must do this firmware grant in the same way that Adaptec, Atmel, Broadcom, Cirrus Logic, Cyclades, QLogic, Ralink, and LSI and lots of other companies have granted distribution firmware to be used by others." He concluded by requesting that the open source community contact Intel to help get them to change their policies, "let's win back the rights to run the hardware we purchased."

OpenBSD creator Theo de Raadt [interview] announced that Intel has refused his request to permit that the firmware for their wireless chipsets be made freely distributable. He explains, "I had asked for free terms under which we (and Linux, anyone) can redistribute the firmwares for their wireless chipsets. Without these firmware files included in OpenBSD, users must go do some click-through license at some web site to get at the files. Without those files, these devices are just bits of metal, plastic, and sand." Intel is one of several companies being approached by OpenBSD in a coordinated effort to try and free up the availability of firmware for wireless chipsets [story]. Several vendors including Symbol, Zydas, and Atmel have responded favorably, licensing their firmwares so that they can be distributed freely with OpenBSD.

As to the reason Intel refused to update their licensing, Theo explained that they referenced obligations to outside parties. Further clarification as to exactly what that means was not provided by the company. Theo went on to note that though this concludes his dealings with Intel, users are still encouraged to contact them and express their concern for this policy, "maybe they will listen to enough customers, or they will learn to not make this mistake again with future chipsets. I for one have already decided that I will never recommend an Intel product to anyone ever if there is choice. (There is almost always choice)."