In association with heise online


The subsystem introduced in 2.6.35 for infra-red hardware now offers interfaces that the LIRC userspace daemon can use to exchange raw data with infra-red receivers and transmitters; for instance, the daemon decodes the IR data if the kernel driver is not able to (1, 2). A number of new drivers for IR hardware from various vendors were added to the still young IR subsystem. Most of them are ports of LIRC drivers that used to be maintained externally; a number of LIRC drivers that have not yet migrated were put into staging for the time being – for details, see "Minor gems" in the fourth part of the "Coming in 2.6.36" series.

Originally called Compcache and later renamed Ramzswap, the staging driver used to create a compressed block device in RAM has had its name changed again and is now called Zram (1, 2, 3). One driver was mature enough to be moved from staging to another point in the kernel source code by means of "git mv": the "Restricted Access Region Register Driver" rar_register, which leaves the staging area in 2.6.36. It was added to the kernel a year ago as "rar" in version 2.6.32 and is good for Mobile Internet Devices (MIDs) that have an Atom processor.

Thanks to changes to the USB subsystem, it now provides better support for some of the extensions of USB 2.0 described in Addendum 1.1 of the EHCI specification such as per-port change events and improved link power management (1, 2, 3). The USB code now supports the power-saving function of PCI USB controllers usable during runtime in addition to some vendor-specific wakeup flags that Intel integrated in the USB controller of some of its I / O controller hubs. The xHCI driver for USB 3.0 now reportedly transmits data faster and supports isochronous transfers.

Which drivers were changed

Information about the changes to individual Linux kernel files can be found through the Git web front end at – this, for example, allows users to find out whether there have been changes to the drivers used on their own systems. To do this, however, users need to know where in the Linux kernel's source code tree the driver files are located. For the heavily modular distribution kernels the modinfo program is often helpful when searching:

$ /sbin/modinfo e100 e1000 | grep filename:
filename: /lib/modules/[...]/kernel/drivers/net/e100.ko
filename: /lib/modules/[...]/kernel/drivers/net/e1000/e1000.k

If a compiled module is, for example, located at [...]/kernel/drivers/net/e100.ko, its source code in the Linux source code archive can usually be found in a file with a similar name in the drivers/net/ directory – for example e100.c for the e100 driver for Intel 100 MBit networking hardware. Other modules like the e1000 driver for Intel's PCI Gigabit LAN chips, on the other hand, have a whole directory to themselves. If the approximate location of the driver source code is known, users can navigate to the respective source code files in the tree view of the Git web interface and can then retrieve an overview of the latest file or directory changes via the history link. In the network driver directory, changes to the driver code of e100 (drivers/net/e100.c) and e1000 (drivers/net/e1000/), for example, can be displayed and examined in this way.

Next: In brief & Statistics

Print Version | Permalink:
  • Twitter
  • Facebook
  • submit to slashdot
  • StumbleUpon
  • submit to reddit

  • July's Community Calendar

The H Open

The H Security

The H Developer

The H Internet Toolkit