KernelNewbies:

Linux 2.6.21 Released 25 April, 2007 (full SCM git log)

Contents

  1. Short overview (for news sites, etc)
  2. Important things (AKA: ''the cool stuff'')
    1. VMI (Virtual Machine Interface)
    2. KVM updates
    3. Dynticks and Clockevents
    4. ASoC
    5. Dynamic kernel command-line
    6. Optional ZONE_DMA
    7. devres
    8. GPIO API
    9. New drivers
  3. Crashing soon a kernel near you
  4. Various core changes
  5. Architecture-specific changes
  6. Filesystems
  7. Networking
  8. Various subsystems
    1. Software suspend
    2. crypto/audit
  9. Drivers
    1. Network drivers
    2. SATA/IDE/SCSI
    3. Graphics
    4. ALSA
    5. Input
    6. USB
    7. V4L
    8. Cpufreq
    9. ACPI
    10. I2C
    11. Various

Short overview (for news sites, etc)

2.6.21 improves the virtualization features merged in 2.6.20 with VMI (http://lwn.net/Articles/175706), a paravirtualization interface that will be used by Vmware (and maybe -probably not- Xen) software. KVM does get initial paravirtualization along with live migration and host suspend/resume support (http://lwn.net/Articles/223839). 2.6.21 also gets a tickless idle loop mechanism called "Dynticks" (http://lwn.net/Articles/223185), a feature built in top of "clockevents" which unifies the timer handling and brings true high-resolution timers. Other features are: bigger kernel command-line, optional ZONE_DMA; support for the PA SEMI PWRficient CPU, for a Cell-based "celleb" architecture from Toshiba, better PS3 support: support for NFS IPv6, IPv4 <-> IPv6 IPSEC tunneling support, UFS2 write support, kprobes for PPC32, kexec and oprofile for ARM, public key encryption for ecryptfs, Fcrypt and Camilla cipher algorithms, NAT port randomization, audit lockdown mode, many new drivers and many other small improvements.

Important things (AKA: ''the cool stuff'')

VMI (Virtual Machine Interface)

VMI is a virtualization feature built in top of the paravirt_ops paravirtualization implementation introduced in 2.6.20.

Paravirtualizated kernels need to be modified to run under a hypervisor. The goal of VMI is to become the common paravirtualization interface for hypervisors like Xen and Vmware. Vmware will certainly use VMI; Xen was going to use VMI but they may develop their own VMI-like interface. Any hypervisor can use VMI by providing a (GPLed) ROM; the ROM describes how the low-level VMI kernel must use the hypervisor. A VMI-enabled kernel can also boot on bare hardware and no hypervisor with no performance impact (commit 1 2, 3, 4, 5, 6, 7, 8)

More details about VMI can be found in this LWN article: "The VMI virtualization interface"

KVM updates

KVM does evolve at a very fast pace, due to its clean design. This release (KVM-15) brings many new features:

Recommended LWN article: "KVM-15"

(commit 1, 2, 3, 4, 5)

Dynticks and Clockevents

Recommended LWN article: "Clockevents and dyntick"

(This feature touches a lot of low-level x86 code, so regressions are possible. If you have problems with 2.6.21, please report it)

Clockevents is a building block of dynticks. An example of a clock device is the device which makes timer interrupts. Previously, the handling of such devices was made in architecture-specific code preventing a unified method of using those devices. The clockevents patch unifies the clock device handling so the kernel can use the timer capabilities of those devices in a unified manner. This also allows to implement true high-resolution timers.

Dynticks (aka: dynamic ticks) is a configurable feature for x86 32bits (x86-64 and ARM support is already done but not ready for this release; PPC and MIPS support are in the works) that changes the heart of the mechanism that allows a system to implement multitasking. To know what dyntick does, first you should know some basics: Traditionally, multitasking is implemented using a timer interrupt that is configured to fire N times in a second. Firing this interrupt causes a call to the operating system's process scheduler routines. The scheduler then decides which process should run next - either the process that was running before the timer interrupt was fired or another process. This is how true multitasking is implemented in all the general-purpose operating systems and is also what stops processes from being able to monopolize the CPU time: the timer interrupt will be fired regardless of what the process is doing and the operating system will be able to stop it (pre-emption).

N (the number of times the timer interrupt is fired in each second, aka 'HZ') is a hard coded compile-time architecture-dependent constant. For Linux 2.4 (and Windows), HZ=100 (the timer interrupt fires 100 times per second). 2.6 increased HZ to 1000 for several reasons. 100 was the HZ value that x86 had been using since forever and it didn't really make a lot of sense in modern CPUs that run much faster. Higher HZ means smaller process time slices, which improves the minimum latency and interactivity. The downside is higher timer overhead (negligible in modern hardware, although some server-oriented distros package kernels with HZ=100 because of minor performance gains) and high pitch noises in some systems due to cheap, low-quality capacitors.

Anyway, the issue is that the timer is fired HZ times in every second - even if the system is doing nothing. Dynticks is a feature that stops the system from having to always wake up HZ times per second. When the system is entering the idle loop it disables the periodic timer interrupt and programs the timer to fire the next time a timer event is needed. This means your system will be 'disabled' while there's nothing to do (unless an interrupt happens - e.g. an incoming packet through your network). For now, this is all dynticks does. However, this infrastructure will enable the creation of an innovative power-saving feature - when dynticks is in "tickless" mode and the system is waiting for the timer interrupt, the power-saving feature of modern CPUs will be used for longer. This can save a few watts when a laptop is idle. It's also very useful for virtualization software - since the virtualization host has to execute all those timer notifications there's some overhead even when not doing anything (especially when there are lots of virtual cpus); with Dynticks the host handles less timer notifications when the virtual guest is doing anything.

Dynticks adds some nice configurable debugging features. /proc/timer_list prints all the pending timers, allowing developers to check if their program is doing something when it should be doing nothing. /proc/timer_stat collects some timer statistics allowing detection of sources of commonly-programmed timers.

(commit 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28)

ASoC

The ASoC (ALSA System on Chip) layer has been added to the ALSA sound system. Its aim is to provide improved support for sound processors on embedded systems. The ASoC core is designed to allow reuse of codec drivers on other platforms, reuse of platform specific audio DMA and DAI drivers on different machines, easy I2S/PCM digital audio interface configuration between codec and SoC, and allow machines to add controls and operations to the audio subsystem - e.g. volume control for speaker amp.

To achieve all this, ASoC splits an embedded audio system into 3 components: 1. Codec driver: The codec driver is platform independent and contains audio controls, audio interface capabilities, codec dapm and codec IO functions 2. Platform driver: The platform driver contains the audio dma engine and audio interface drivers (e.g. I2S, AC97, PCM) for that platform. 3. Machine driver: The machine driver handles any machine specific controls and audio events, i.e. turning on an amp at start of playback.

It includes a dynamic power management subsystem, designed to allow portable and handheld Linux devices to use the minimum amount of power within the audio subsystem at all times. It is independent of other kernel PM and as such, can easily co-exist with the other PM systems. DAPM is also completely transparent to all user space applications as all power switching is done within the ASoC core. No code changes or recompiling are required for user space applications. DAPM makes power switching decisions based upon any audio stream (capture/playback) activity and audio mixer settings within the device.

A number of platform and codec drivers for ASoC have been merged as well.

(commit 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39)

Dynamic kernel command-line

The current implementation stores a command-line buffer allocated to COMMAND_LINE_SIZE (a compile-time constant) size - 256 bytes on x86. This is not enough space today, some systems hit a limit when they use too many module parameters, video settings, initramfs parameters etc. It's possible to increase COMMAND_LINE_SIZE to a greater value, but there's a problem: a static buffer of that size (say, 2KB) will be allocated even if you aren't using all of it.

So in 2.6.21 the size of the boot command line is allocated dynamically. A static buffer is still allocated (2K in i386), but the contents are copied into a dynamically-allocated buffer with the exact size, then the static buffer is freed with the rest of the initdata data.

(commit 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31)

Optional ZONE_DMA

ZONE_DMA was created for handling x86-specific ISA DMA uglities. Some arches do not need ZONE_DMA at all, the newer x86 systems are not needing ISA DMA and are starting to include IOMMUs. 2.6.21 makes possible to completely disable ZONE_DMA. This also makes possible some compiler optimizations.

(commit 1, 2, 3, 4, 5, 6, 7, 8, 9, 10)

devres

"devres" is an optional subsystem for drivers that greatly simplifies the task of driver housekeeping, if you have to acquire+map then later unmap+free a bunch of device-related resources (MMIO, PIO , IRQs, iomap, PCI, DMA resources). The aim is to make easier for programmers to allocate & free resources & handle errors for a driver writer. A device driver can allocate arbitrary size of devres data which is associated with a release function. On driver detach, release function is invoked on the devres data, then, devres data is freed. (commit)

Recommended LWN article: "The managed resource API"

GPIO API

The GPIO API implements a simple and minimalist programming interface for GPIO APIs. A "General Purpose Input/Output" (GPIO) is a flexible software-controlled digital signal. They are provided from many kinds of chips, and are familiar to Linux developers working with embedded and custom hardware.

(commit 1, 2, 3, 4, 5, 6)

New drivers

Here are some important new drivers that have been added to the Linux tree:

Crashing soon a kernel near you

This is a list of some of the ongoing patches being developed at the kernel community that will be part of future Linux releases. Those features may take many months to get into the Linus' git tree, or may be dropped. The features are tested in the -mm tree, but be warned, it can crash your machine, eat your data (unlikely but not impossible) or kidnap your family (just because it has never happened it doesn't mean you're safe):

Various core changes

Architecture-specific changes

Filesystems

Networking

Various subsystems

Software suspend

crypto/audit

Drivers

Network drivers

SATA/IDE/SCSI

Graphics

ALSA

Input

USB

V4L

Cpufreq

ACPI

I2C

Various

KernelNewbies: Linux_2_6_21 (last edited 2017-12-30 01:30:20 by localhost)