Power consumption is a hot topic — from laptop, to datacenter. Recently, the Linux kernel has made huge steps forward in power conservation, thanks to tickless kernels.

Power consumption is a hot topic — from laptop, to datacenter. Recently, the Linux kernel has made huge steps forward in power conservation. This article focuses on the so-called "tickless idle" feature being integrated into the 2.6.21 and 2.6.23 kernel versions.

Confronting multi-core anxiety and what the new processors mean for the future of commodity clusters.

Kexec can spawn a kernel-over-a-kernel without the overhead of boot firmware, while kdump can reliably collect a crash-dump using the services of kexec.

Tried of booting a debug kernel? Kprobes can intrude into your kernel code and extract debug information or apply run time medication.

Many Linux subsystems, such as the /dev filesystem, hotplug, module autoload, and microcode download have undergone significant changes with the introduction of the new device model. Learn about udev, sysfs, kobjects, classes, and more.

Interrupt handlers are an integral part of most device drivers. Learn to implement interrupt handlers and bottom halves.

Look at messages generated during kernel boot and explore the internals of the more interesting ones.

Kernel helper interfaces make life easier for developers. Learn about notifier chains, completion functions and error handling aids.

The use of standard kernel helper facilities simplifies your code, weeds out redundancies from the kernel, and helps long-term maintenance. And since the helpers are bug-free and optimized, you inherit those benefits for free.

Learn how the kernel views physical memory.

Most embedded devices boot from flash memory and have data resident on flash-based storage. Here’s how to use flash devices while embedding Linux.

The x86 kernel has direct and indirect dependencies on the system BIOS. Here’s a look at some of the guts.

Multiple threads of execution need to be synchronized to avoid data corruption and even system freezes.

The kernel keeps track of the flow of time. It provides services to sleep wait for long periods and busy wait for short periods, can schedule events to run at a future time, and can do periodic work with microsecond precision. Here’s a look at kernel time.

Kernel threads are used to implement background tasks inside the kernel. They are similar to user processes, but live in kernel address space. Here’s how to use them.

Profiling helps find code bottlenecks. Trace tools provide the ability to extract and interpret details about code execution.

Debuggers make kernel internals more transparent. On Linux, they come in different flavors: The Kernel debugger, kdb, the Kernel GNU debugger, kgdb, the GNU debugger, gdb, and JTAG- based debuggers. Learn how to use the former three in this month’s column.

Thanks to plug-and-play devices like PC cards, you can backup gigabytes of data onto a stamp-sized device or enable your laptop with diverse networking technologies.

Technologies like Wi-Fi, GPRS, and miniature storage devices are ubiquitous today as PCMCIA or CF cards. The Linux kernel supports PCMCIA devices on a variety of architectures.

Look at the internals of a line discipline and implement a simple line discipline for a serial touch screen controller.

Inter-Integrated Circuit, or “i2c” (pronounced “I squared C”), is a serial bus/protocol that’s widely used to interface hosts with devices such as EEPROM memory, audio codecs, and specialized chips that monitor parameters like temperature and power supply voltages. Take a look at how the kernel supports i2c.

Some of the recent Intel microprocessors have the capability of correcting specific hardware bugs by loading a sequence of bits called a "microcode update" into the CPU. This feature is available on all processors in the Intel P6 family, including Pentium Pro, Celeron, Pentium II, Pentium III, Pentium II Xeon, Pentium III Xeon, and the newly released Pentium 4. This feature is applicable to both single-processor and multi-processor (SMP) systems.

In last month's column, we took a look at the practice of invoking system calls from within kernel code. This month's column will deal with how a complete network server can be implemented as a kernel thread. The sample code shown throughout this column implements a simplified TFTP server. See the Features of the Sample Code sidebar, pg. 80, for more information.

One of the most renowned features of Unix is the clear distinction between what occurs in "kernel space" and what occurs in "user space." This column will describe how to invoke kernel system calls from within kernel code. This is a first step towards understanding how to build a kernel-resident application, such as a high-performance Web server.

Last month I gave an overview of the USB kernel subsystem, but I didn't have the space needed to show real code at work. This month we'll fill the gap by looking at sample drivers implementing input devices in the USB framework. The code being introduced has been developed and tested on version 2.3.99-pre6 of the Linux kernel, running on an Intel x86 machine.

In this column, Alan Cox has written many good introductions on how to write kernel drivers for various types of hardware, from mice to SCSI boards to radio interfaces to video cards. However, it's not just the kernel that needs good drivers for new hardware -- with the increasing focus on Linux on the desktop, hardware support for XFree86 is just as important.

The Universal Serial Bus, or USB, is a new type of peripheral interconnect that has become popular in recent years and is now standard equipment on most PCs and laptops. USB is an external interface, in that USB devices plug into ports outside of your PC's case; this is as opposed to internal interfaces, such as PCI.

With Linux 2.4 right around the corner, now would be a very good time to discuss the new packet observation and filtering mechanism that were introduced during the 2.3 kernel development, which iscalled netfilter. I discussed the netfilter architecture briefly back in my Best Defense column in October 1999 (http://www.linux-mag.com/1999-10/bestdefense_01.html), and more thoroughly in the January 2000 issue of Linux Magazine.

The role of the kernel is mostly related to hardware control, as user-space programs need a way of referring to hardware devices that they wish to use. Some hardware devices are used implicitly, through interfaces such as sockets or filesystems. However, it is often necessary to refer to a hardware device directly -- such as a particular serial port or hard-disk partition. This is accomplished through the use of special device files that are usually found in the /dev directory. The special files are not associated with data stored in the disk; rather, they correspond to particular hardware devices. When user programs access and use these special files, the operation is passed to a device driver in the system kernel. For example, when you issue an open and a read on the /dev/ttyS0 file, data is read from a serial port; the serial-port device driver is invoked whenever /dev/ttyS0 is accessed.

In the Linux (or Unix) world, most network interfaces, such as eth0 and ppp0, are associated with a physical device that is in charge of transmitting and receiving data packets. However, some logical network interfaces don't feature any physical packet transmission. The most well-known examples of these "virtual" interfaces are the shaper and eql interfaces. This month, we'll look at how this kind of interface attaches to the kernel and to the packet-transmission mechanism.

Peripheral Component Interconnect (PCI) is a widely used bus standard that provides several advantages over other bus standards, such as EISA. Standard on most Pentium motherboards, PCI is a fast, wide (32-bit and 64-bit), and processor-independent bus. When PCI support was first added to Linux, the kernel interface was a wrapper to the PCI BIOS32 functions. There were several problems with this approach:

Last month I began to develop a very simple camera driver as an illustration of Linux's video-capture interface. What we need to do now is to provide the functions to control the use of the device and to query its facilities. As with the radio driver, the major control interface is via the ioctl() function (Listing One). Video-capture devices support the same tuner calls as radio devices, and also support additional calls to control how the video functions are handled. In this simple example the card has no tuners, to avoid making the code complex.

Last month I talked about how to write a device driver for radio-tuner cards. This month, I'll cover video-capture devices, which share the same interfaces as radio devices.

Video4Linux is the Linux 2.2 interface to TV- and radio- related cards. Prior kernels had a jumble of incompatible add-on modules. This made it very hard to write a general-purpose video application for Linux. A wide variety of radio interfaces are available for PCs, and these are generally very simple to program. Usually, the biggest problem with supporting such devices is extracting documentation from the vendor.

Last month I walked through the steps of writing a serviceable mouse driver that contained a couple of bugs and that would not work with asynchronous I/O. In this month's column I'll smooth things out a bit. But first, I think we should take a look at some bugs.

Mice are conceptually one of the simplest device drivers in the Linux operating system. Not all mice are handled by the kernel; rather, there is a two-layer abstraction. The kernel provides services for mice that cannot be driven directly by the user libraries and applications. That is, mice other than serial mice. On top of this library and application, programs (selection or gpm) provide a single common interface to all mice whether supported directly by the kernel or via a serial line.

In last month's article, we looked at writing a basic Linux SCSI driver -- one that basically sucked. Actually, this driver was worse than planned because it contained a bug which anyone running on an SMP box would have found pretty quickly.

This month, I'm going to talk about writing a driver for a simple SCSI controller under Linux. The Linux kernel SCSI layer does most of the work for SCSI device handling, so a simple SCSI driver is relatively painless to write. For more advanced devices, however, the kernel's SCSI code is actually too clever -- there are plans afoot to streamline it and solve these problems.

There is an increasing number of people running Linux on their Power Macintoshes. One of the advantages of running Linux (as opposed to other variants of UNIX) on a Power Mac is that the Linux source includes drivers for a large number of PCI cards. All of the current Power Macs use the PCI bus as their internal I/O bus and many have PCI expansion card slots, allowing users to install any of the wide range of PCI expansion cards which are available today. The drivers in the Linux source will usually work on a Power Mac, but often only after some tweaking. The problem is usually that the driver author has made some assumptions that are true on an Intel PC but not on other machines. In this column, I will discusses some of those assumptions and how driver authors can make sure that their drivers will work not only on an Intel PC, but also on the Power Mac and other machines.