KernelNewbies:

Released 29 November, 2006 (full SCM git log)

Short overview (for news sites, etc)

Linux 2.6.19 includes the clustering GFS2 filesystem (http://sources.redhat.com/cluster/); Ecryptfs (http://lwn.net/Articles/156921) the first experimental version of EXT4 (aimed at developers), support for the Atmel AVR32 architecture, sleepable RCU (http://lwn.net/Articles/202847), improvements for NUMA-based systems, a "-o flush" mount option aimed at FAT-based hotpluggable media devices (mp3), physical CPU hotplug and memory hot-add in x86-64, support for compiling x86 kernels with the GCC stack protection, vectored async I/O (http://lwn.net/Articles/202449), Netlabel subsystem (http://lwn.net/Articles/204905), allow to disable compilation of the block layer, IDE Parallel-ATA drivers based in libata (http://lwn.net/Articles/198344), Granular IPSec associations for use in MLS environments, add the Netlabel subsystem (http://lwn.net/Articles/204905), Mobile IPv6 (RFC 3775), some new drivers, improved support for many already existing drivers, and many other things.

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

GFS2

GFS2 is a clustering filesystem developed mainly by Red Hat (after purchasing Sistina and opening the source code, since it was closed at Sistina). It's not the first: OCFS2, another clustering filesystem developed by Oracle, was already merged in Linux 2.6.16. Clustering filesystems allow to share a filesystem between several machines with no compromises. GFS includes his own DLM (distributed locking manager) and a userspace API interface for that DLM.

Like OCFS2 and like any other filesystem that wants to be merged in the linux kernel, GFS2 developers asked for submission long time ago. They were asked to fix things (even considering that GFS2 had already been developed at Sistina and it was already a stable final product), they submitted it again, they were asked to fix more things, and so on, for a long period of time. Their developers have fixed every thing they were asked to fix. Because of their hard work, GFS2 is now ready to be merged, nobody opposes to it, and everyone is happy. (Amazing, isn't it? In fact, 3 new filesystems are being merged in 2.6.19 and nobody is flaming nobody, quite the contrary)

GFS2 project page; Source code for GFS2 (840 KB) and for the DLM (384 KB)

EXT 4

EXT 4 is an evolution (not a redesign from zero) of EXT3. EXT3 never was, and never intended to be, a "state-of-the-art" filesystem (being fair, it was just about adding a journal to ext2 + some features like htree) but rather a solid, reliable filesystem. EXT3 has been quite successful, and despite of the age of its design it works surprisingly quite well in a wide variety of workloads from modern desktops to some big iron SMPs (even if it's not "the best" in some of those workloads). EXT4 is a development and experimental feature. EXT4 will incorporate scalability and reliability enhancements for supporting large filesystems (64 bit) in keeping with increasing disk capacities and some of the "state-of-the-art" feature requirements. But the version in 2.6.19 is missing lots of the features that are already developed but not merged, so it's not useful even for benchmarking. From the Section 2 of the Documentation file:

Features currently available: ability to use filesystems > 16TB, extent format reduces metadata overhead (RAM, IO for access, transactions), extent format more robust in face of on-disk corruption due to magics, internal redundancy in tree

Candidate features for future inclusion: There are several under discussion, whether they all make it in is partly a function of how much time everyone has to work on them: improved file allocation (multi-block alloc, delayed alloc; basically done), fix 32000 subdirectory limit (patch exists, needs some e2fsck work), nsec timestamps for mtime, atime, ctime, create time (patch exists, needs some e2fsck work), inode version field on disk (NFSv4, Lustre; prototype exists), reduced mke2fs/e2fsck time via uninitialized groups (prototype exists), journal checksumming for robustness, performance (prototype exists), persistent file preallocation (e.g for streaming media, databases).

Features like metadata checksumming have been discussed and planned for a bit but no patches exist yet so I'm not sure they're in the near-term roadmap. The big performance win will come with mballoc and delalloc. CFS has been using mballoc for a few years already with Lustre, and IBM + Bull did a lot of benchmarking on it. The reason it isn't in the first set of patches is partly a manageability issue, and partly because it doesn't directly affect the on-disk format (outside of much better allocation) so it isn't critical to get into the first round of changes

(LWN article JBD2 source, EXT 4 source

ECRYPTFS

Coming from IBM, ecryptfs aims to bring "enterprise level" file encryption to the masses.

"Oh no, another filesystem!". No, Ecryptfs is not a traditional filesystem: it doesn't implement his own disk format for example. From this LWN article:

The eCryptfs developers took the stacking approach, meaning that, rather than implement its own platter-level format, eCryptfs sits on top of another filesystem. It is, essentially, a sort of translation layer which makes encrypted file capabilities available. The system administrator can thus create encrypted filesystems on top of whatever filesystem is in use locally, or even over a network-mounted filesystem. [...] Rather than encrypt the filesystem as a whole, eCryptfs deals with each file individually

(Reading the rest of the LWN article is recommended. There's also an Ecryptfs paper from the 2005 Ottawa Symposium - page 209 and onwards)

Is it better to encrypt the whole disk using cryptoloop/dmcrypt, or use ecryptfs? You decide. Ecryptfs avoids the overhead of a fully encrypted filesystem by only encrypting the files you really want to encrypt, and it also allows to encrypt different files in different ways. Ecryptfs tries to make file encryption available in an easy way for the masses. It "aims to combine the flexibility of GnuPG encryption with the transparency of a kernel service" [...] "Think of eCryptfs as a sort of 'gnupgfs'". If you're interested, you will find the userspace tools and more information available in the ecryptfs sourceforge site. You can also read the Ecryptfs documentation and the Ecryptfs code (232 KB).

Libata PATA (Parallel ATA) merge

By "Parallel ATA" we mean all the ATA/IDE controllers and drives that we have been using for years before SATA. Almost from the start, one of the objectives of some kernel hackers was to replace the IDE drivers available in drivers/ide (everything under the "Device drivers -> ATA/ATAPI/MFM/RLL support" configuration menu) with a reimplementation on top of libata (i.e.: the "SATA layer"). Drivers/ide suffers from many ugly and obscure problems, and re-implementing it on top of libata has been much easier than fixing the unfixable drivers/ide mess - most of the porting work has been done by Alan Cox (a consequence of this PATA merge is that libata and all its SATA drivers have also been moved from drivers/scsi (available in the "Device drivers -> SCSI device support -> SCSI low-level drivers" submenu) to drivers/ata (now "Device drivers -> Serial ATA (prod) and Parallel ATA (experimental) drivers"), and all the CONFIG_SCSI_FOOBAR options for the individual SATA drivers have been changed to CONFIG_FOOBAR, so this means you may need to reconfigure your SATA configuration options)

This means 2.6.19 may have two drivers for your PATA-based device: The old IDE driver under "Device drivers -> ATA/ATAPI/MFM/RLL support" and an alternative driver under "Device drivers -> Serial ATA (prod) and Parallel ATA (experimental) drivers" (along with the rest of the SATA drivers)

What one must you choose? Well, the safe option is using the old driver: The old drivers will continue working just as they did before. There'll be no changes if you continue using the old drivers.

What do the new libata-based PATA drivers offer to you?

Eventually, the new libata-based PATA drivers will get more stable, so the old drivers in drivers/ide may get deleted as the new drivers fulfill all needs of the IDE users and become feature-complete. But this certainly won't happen anytime soon. No old drivers will be deleted if there's not a working libata-based replacement. You can read the latest status report written by Alan Cox. It'd certainly be useful if you could give it a try and report back how well it works to linux-kernel@vger.kernel.org or bugzilla.kernel.org - even if it works fine, it'll be useful to know what systems do work (be sure to include the necessary information mentioned in the previous status report). (libata PATA code)

It is probably worth reiterating that if you have SATA drives, and you do a make oldconfig from a 2.6.18 or previous kernel, your system will not boot unless you specifically go in and enable the new SATA subsystem, and the driver for your controller.

Removal of selected OSS drivers

Since 2.6 was released, ALSA has been the "official" sound subsystem. OSS drivers were kept for compatibility - ALSA also implements an OSS compatibility layer. However, there's a big number of ALSA drivers and OSS drivers targeting exactly the same hardware. Usually, the OSS ones are undermaintained (or not maintained at all). And ALSA already implements OSS compatibility. So....

...it's possible to remove old OSS drivers, as long as there's an equivalent ALSA driver, and as long as that driver has no regressions that don't allow users to migrate (drivers with no ALSA equivalent or with known regressions have NOT been deleted). In 2.6.19, those OSS drivers are being removed. If when migrating users find something wrong in the ALSA drivers, they should report it in the ALSA bug tracking system and work with developers to fix them. Yes, we know there're users that feel just fine with the OSS drivers, but it doesn't help to the kernel to keep those old drivers around. By forcing people to migrate to ALSA drivers, the ALSA drivers will be improved and fixed. Overall, the linux sound subsystem will only get better. Many thanks to all the hackers that coded them.

A total of 1.79 MB of OSS drivers will be removed. To see a list of source files being removed, see the commit link. Hardware that is forced to use ALSA drivers include:

AD1980 AC97 plugin; ALI 5455; Alchemy Au1000 (MIPS); AWE32/SB32/AWE64 Wavetable driver; C-Media; Cirrus Logic-Crystal CS4281; Ensoniq ES1370/Asahi Kasei AK4531; ESS Technology Solo1 (ES1946); Fortemedia FM801; Gravis Ultrasound; ASP's and Lasi's Harmony sound chip; ICS2101 mixer of GUS v3.7; OPTi MAD16 compatible audio chips; ESS Maestro/Maestro-2/Maestro-2E/Maestro3/Allegro; Turtle Beach Maui and Tropez; Yamaha YMF701B aka OPL3-SA; RME9652/36 "Hammerfall" Driver; Aztech Sound Galaxy cards; S3 Sonic Vibes; Turtle Beach Wavefront Series (Maui, Tropez, Tropez Plus); Wavefront ICS2115 MIDI; Yamaha YMF7xx

AVR32 Architecture

2.6.19 adds support for the Atmel AVR32 architecture, implemented and supported by Atmel Corporation.

AVR32 is a new high-performance 32-bit RISC microprocessor core, designed for cost-sensitive embedded applications, with particular emphasis on low power consumption and high code density. The AVR32 architecture description, including the instruction set, can be found in the AVR32 Architecture Manual. The Atmel AT32AP7000 is the first CPU implementing the AVR32 architecture; it features a 7-stage pipeline, 16KB instruction and data caches and a full Memory Management Unit and a large set of integrated peripherals (full data sheet); while the CPU core implementation including caches and MMU is documented by the AVR32 AP Technical Reference. Information about the AT32STK1000 development board can be found here, including a BSP CD image, development tools (binaries and source/patches) and a root filesystem image suitable for booting from SD card. Alternatively, there's a preliminary "getting started" guide available at http://avr32linux.org/twiki/bin/view/Main/GettingStarted which provides links to the sources and patches you will need in order to set up a cross-compiling environment for avr32-linux

Source code can be found here (arch/av32)

Sleepable RCU (Read Copy Update)

(LWN article by Paul McKenney, who implemented it)

Like in spinlocks, preemptable RCU read-side critical sections were prohibited. However, many people had frequently requested a "sleepable RCU". Furthermore, the realtime capabilities being developed in the -rt patch required that those critical sections were preemptible. So a RCU variant permitting read-side blocking has been developed, and a SRCU-base notifier chain has also been merged (commit), (commit)

Configurable block layer

2.6.19 makes it possible to disable the block layer. Not all embedded devices require it, some can make do with just JFFS2, NFS, ramfs, etc - none of which require the block layer to be present (commit 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20)

Tracking maximum allowable latency for power saving

2.6.19 adds an infrastructure to track "maximum allowable latency" for power saving policies (LWN article). The reason for adding this infrastructure is that power management in the idle loop needs to make a tradeoff between latency and power savings (deeper power save modes have a longer latency to running code again). The code that today makes this tradeoff just does a rather simple algorithm; however this is not good enough: There are devices and use cases where a lower latency is required than that the higher power saving states provide. An example would be audio playback, but another example is the ipw2100 wireless driver that right now has a very direct and ugly acpi hook to disable some higher power states randomly when it gets certain types of error. The proposed solution is to have an interface where drivers can 1) announce the maximum latency (in microseconds) that they can deal with 2) modify this latency 3) give up their constraint (commit), (commit)

Some new drivers

Here are some important drivers that have been added to the Linux tree - note that it says 'drivers', only new important drivers are listed today. Other small drivers are listed below; the already available drivers also add support for new devices and some are listed below but support for new devices is added so fast that it's impossible to keep track of all of them.

Other stuff

Arch-independent changes in the kernel core

Architecture-specific changes

Filesystems

SELinux

Networking

Crypto

CPUFREQ

Drivers and other subsystems

Video

USB

Add Playstation 2 Trance Vibrator driver (commit), add driver for the Phidgets Inc Motorcontrol (commit), add AIRcable USB Bluetooth Dongle Driver (commit), add Moschip 7840 USB-Serial Driver (commit), add basic infrastructure in usbcore for autosuspend/autoresume (commit), new gmidi, a MIDI Gadget class driver - glue between the USB gadget interface and the ALSA MIDI interface (commit), add TIOCGSERIAL and TIOCSSERIAL ioctl calls to ark3116 (commit), add AX88178 support to asix (commit), add support for many devices in the usbtouchscreen driver (commit), add ADU support for Ontrak ADU devices (commit), add rio karma eject support (commit), client driver for ELAN Uxxx adapters in ftdi-elan (commit), add serial mos7720 driver (commit)

Input devices

Implement a new Force Feedback interface for drivers (userspace interface is untouched) (commit), (commit), (commit), (commit), (commit), (commit), (commit); add driver for Touchwin serial touchscreens (commit), another for Penmount serial touchscreens (commit), another for Touchright serial touchscreens (commit), another driver for stowaway serial keyboards (commit); and add support for non-pressure-sensitive touchscreens in elo driver (commit), add support for Acer Travelmate 2424NWXCi in wistron driver (commit), and add support Microsoft Natural Elite Pro keyboards (commit)

Sound

libata/IDE

V4L/DVB

Network drivers

SCSI drivers

Hardware monitoring drivers

Various drivers

KernelNewbies: Linux_2_6_19 (last edited 2017-12-30 01:30:02 by localhost)