« previous 1 2 3 4 5 6 next »

The Dodgy Corner

There have been numerous changes to the Wi-Fi drivers in the staging area, where drivers which do not yet meet the requisite quality standards are collected for further development. The rtl8192SU driver for similarly named Realtek Wi-Fi chips is one new addition, and is joined by the vt6655 driver for the eponymous VIA chip range (e.g. 1, 2).

Developers have also merged parts of the three staging drivers for Ralink's RT2770, RT2870 and RT3070 Wi-Fi chipsets, substantially reducing the amount of code in the staging area. In the long term, however, this work is probably irrelevant, as the standard rt2x00 Ralink driver should eventually also deal with these chips, with the result that the staging drivers may simply be abandoned. Kernel developers have now taken the first steps along this route with their changes to the rt2x00 driver.

Fast transmissions

As expected, changes to the USB subsystem include the code to support USB 3.0 controllers with their Extensible Host Controller Interface (xHCI) (for example 1, 2, 3, 4, 5). Although various vendors have already released details about USB 3.0 hardware, so far, no actual products have become available. The USB 3.0 support in Linux is, therefore, not particularly relevant for now – but this will probably change in the long run; after all, the previous two USB interface generations have been resoundingly successful.

An overview of the changes to the FireWire code is available in the two main git-pull requests submitted by FireWire maintainer Stefan Richter (1, 2). Among other things, the maintainer highlights the added support for "IPv4 over IEEE 1394" (networks via FireWire) in the more recent of the Linux kernel's two FireWire stacks. He also points out that the more recent "firewire" stack is no longer classified as experimental, and that the distributions should, therefore, give it preference in the future. According to the maintainer, the new stack offers better performance, better compatibility, more features and improved security.

Body search

The new Fsnotify replaces Dnotify and Inotify and can be used to monitor changes to the file system, such as creation, deletion or modification of files (1, 2, 3). The actual goal of Red Hat employee Eric Paris, who developed Fsnotify, is Fanotify, which builds on Fsnotify and offers virus and malware scanners operating in userspace a handle for checking files for malware before they are actually accessed. Paris recently invited discussion on the concept and design of Fanotify.

The idea arose from long discussions on TALPA, which set out to achieve the same purpose, but failed to win over kernel developers. Background information can be found in the LWN.net articles "Kernel-based malware scanning", "The TALPA molehill" and "The fanotify API".

Detailed road testing

Operating partly in the kernel and partly in the userspace, the "performance counters" code can be used for retrieving the performance data offered by modern processors. This performance data quantifies various CPU processes that have an impact on CPU performance Ð providing an in-depth analysis and allowing developers to optimise the code segments relevant to processing speed down to the last detail for each CPU.

Occasionally abbreviated to "perf_counter", performance counters should not be confused with Perfmon ("hardware-based performance monitoring interface for Linux"), which has offered similar functionality for years – the kernel hackers didn't include it in the Linux source code because they were dissatisfied with some of Perfmon's properties. The article "Duelling performance monitors" published on LWN.net in late 2008 provides some details concerning this competitive situation. Use of the performance counters is described in the more recent article "Perfcounters added to the mainline" on LWN.net. Further background information can also be found in the documentation.

Ingo Molnar has introduced not only the performance counters, but also numerous other changes affecting the tracing area he maintains. In his git-pull request, he suggests that the main development phase of trace points is likely to be completed in the near future. He also highlights improved filters, internal restructuring measures and performance optimisation. Some of the possibilities offered by the tracing infrastructures of current kernels are explained in Sony developer Tim Bird's presentation "Measuring Function Duration with Ftrace", which we already mentioned in the article "The nitty gritty – The proceedings of the Linux Symposium 2009 ....".

The kernel hackers also integrated a profiling feature that uses the GCC Coverage Testing Tool (gcov). Kernel developers and testers can from now on use Kmemleak (documentation) to track down memory leaks – however, the tool misinterprets certain situations and constructions, and the results it produces shouldn't be trusted implicitly. Another new tool, Kmemcheck (documentation), detects the use of non-initialised memory areas.

Next: Full of Character

« previous 1 2 3 4 5 6 next »