Linux kernel version 2.6.26 Released 2008 ([http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.26 full SCM git log])

Summary: 2.6.26 adds support for read-only bind mounts, x86 PAT (Page Attribute Tables), PCI Express ASPM (Active State Power Management), ports of KVM to IA64, S390 and PPC, other KVM improvements including basic paravirtualization support, preliminar support of the future 802.11s wireless mesh standard, much [http://linux-uvc.berlios.de/#devices improved webcam support] thanks to a driver for [http://en.wikipedia.org/wiki/USB_video_device_class UVC] devices, a built-in memory tester, a kernel debugger, BDI statistics and parameters exposure in /sys/class/bdi, a new /proc/PID/mountinfo file for more accurate information about mounts, per-process securebits, device white-list for containers users, support for the OLPC, some new drivers and many small improvements

1. Important features (AKA: the cool stuff)

1.1. Read-only bind mounts

Recommended LWN article: [http://lwn.net/Articles/281157/ "Read-only bind mounts"]

Since 2.4.0 Linux has supported bind mounts. Bind mounts are a sort of directory symlinks that allow to share the contents of a directory in two different paths. For example, "mount --bind /foo /bar" will "bind" the contents of /foo not only to /foo, but also /bar. IOW, /foo and /bar would have the same content - and any modification in one directory is visible in the other. This has been useful for things like chroots or ftp/webservers, but until now, if /foo was writable, there was no way to stop /bar from being also writable.

In Linux 2.6.26, you can make those bind mounts read-only. If we made the bind mount in the previous example read-only, the contents of /foo would show up in /bar - but an application trying to modify a file in /bar will not be able to do it (/foo could continue being writable, of course). This has a number of uses. It allows chroots to have parts of filesystems writable. It's useful for containers because users may have root inside a container, but should not be allowed to write to some filesystems. It allows security enhancement by making sure that parts of your filesystem read-only (such as when you don't trust your FTP server), when you don't want to have entire new filesystems mounted, or when you want atime selectively updated.

(The current implementation does not allow to make a bind mount directly read-only: you need to make the bind mound first - mount --bind /foo /bar - and then remount the bind as ro - mount -o remount,ro /bar)

1.2. KVM ported to IA64, PPC and S390

KVM, the virtualization solution included in [http://kernelnewbies.org/Linux_2_6_20#head-bca4fe7ffe454321118a470387c2be543ee51754 Linux 2.6.20], has been rearchitected to give support to architectures others than x86: IA64 (Itanium), S390 and PPC

PowerPC 440: [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=bbf45ba57eaec56569918a8bab96ab653bd45ec1 (commit)]

1.3. Wireless mesh networking (802.11s) draft support

A year ago, in [http://kernelnewbies.org/Linux_2_6_22 Linux 2.6.22], Linux included a new wireless stack. In 2.6.26 that stack is adding support for the draft of wireless mesh networking ([http://en.wikipedia.org/wiki/IEEE_802.11s 802.11s]), thanks to the [http://www.open80211s.org/ open80211s project]

1.4. x86 PAT support

PAT (Page Attribute Table) is a feature found in x86 processors that allows for setting the memory attribute at the page level granularity. PAT is complementary to the MTRR settings which allows for setting of memory types over physical address ranges. However, PAT is more flexible than MTRR due to its capability to set attributes at page level and also due to the fact that there are no hardware limitations on number of such attribute settings allowed. It's not a very new feature: the Linux support for this has been in the works for a long time: the current patches are evolved from ones started in 2006, and there're traces of preliminary patches in 2001. Probably because it's not a critical feature and MTRRs did the job.

Documentation [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d27554d874c7eeb14c8bfecdc39c3a8618cd8d32 (commit)] Code: [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2e5d9c857d4e6c9e7b7d8c8c86a68a7842d213d6 (commit)]

1.5. Per-process securebits

Recommended LWN article: [http://lwn.net/Articles/280279/ "Per-process securebits"]

Filesystem capability support makes it possible to do away with (set)uid-0 based privilege and use capabilities instead. That is, with filesystem support for capabilities but without this present feature, it is (conceptually) possible to manage a system with capabilities alone and never need to obtain privilege via (set)uid-0. Of course, conceptually isn't quite the same as currently possible since few user applications, certainly not enough to run a viable system, are currently prepared to leverage capabilities to exercise privilege. Further, many applications exist that may never get upgraded in this way, and the kernel will continue to want to support their setuid-0 base privilege needs. Where pure-capability applications evolve and replace setuid-0 binaries, it is desirable that there be a mechanisms by which they can contain their privilege. In addition to leveraging the per-process bounding and inheritable sets, this should include suppressing the privilege of the uid-0 superuser from the process' tree of children. The feature added in 2.6.26 can be leveraged to suppress the privilege associated with (set)uid-0. This suppression requires CAP_SETPCAP to initiate, and only immediately affects the 'current' process (it is inherited through fork()/exec()). This reimplementation differs significantly from the historical support for securebits which was system-wide, unwieldy and which has ultimately withered to a dead relic in the source of the modern kernel.

Code: [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3898b1b4ebff8dcfbcf1807e0661585e06c9a91c (commit)]

1.6. KGDB

For many years Linux has not included a kernel debugger. Linus Torvalds vetoed them for years, for reasons that he explained quite well in a [http://linuxmafia.com/faq/Kernel/linus-im-a-bastard-speech.html) well know email]: "When things crash and you fsck and you didn't even get a clue about what went wrong, you get frustrated. Tough. There are two kinds of reactions to that: you start being careful, or you start whining about a kernel debugger [...] Quite frankly, I'd rather weed out the people who don't start being careful early rather than late. That sounds callous, and by God, it _is_ callous. But it's not the kind of "if you can't stand the heat, get out the the kitchen" kind of remark that some people take it for. No, it's something much more deeper: I'd rather not work with people who aren't careful. It's darwinism in software development. [..] I happen to believe that not having a kernel debugger forces people to think about their problem on a different level than with a debugger. I think that without a debugger, you don't get into that mindset where you know how it behaves, and then you fix it from there. Without a debugger, you tend to think about problems another way. You want to understand things on a different _level_."

Despite of those objections, many people wanted a debugger and KGDB is finally going in. It's a remote debugger, it needs two machines. x86 and sparc machines are supported

1.7. Device whitelist on cgroups

Recommended LWN article: [http://lwn.net/Articles/273822/ "Device whitelist on cgroups"]

This feature implements a functionality wanted by some virtualization users: The ability to control the access to devices in a per-container basis. A cgroup is used to track and enforce open and mknod restrictions on device files. More details can be found in the commit link.

Code: [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=08ce5f16ee466ffc5bf243800deeecd77d9eaf50 (commit)]

1.8. Memtest

[http://www.memtest.org Memtest] is a commonly used tool for checking your memory. In 2.6.26 Linux is including his own in-kernel memory tester. The goal is not to replace memtest, in fact this tester is much simpler and less capable than memtest. But it has some advantages, like the fact that it runs in plataforms others than x86, and it's enabled easily with the "memtest" boot parameter.

Code:[http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=272b9cad6e7a2f61b13cfcd7dde0010e02e9376e (commit)], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c64df70793a9c344874eb4af19f85e0662d2d3ee (commit)]

1.9. Export BDI attributes in sysfs

[http://kernelnewbies.org/Linux_2_6_24 Linux 2.6.24] merged per-device dirty thresholds: The limits that the kernel put to the amount of memory that a process can "dirty" changed from being global to be per-device. 2.6.26 exposes a interface in /sys/class/bdi that allow to set several parameters. There's another set of read-only parameters that are exposet in debugfs (debug/bdi/<bdi>/stats)

Code: [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=cf0ca9fe5dd9e3693d935757a7b2fc50fc576554 (commit 1], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fa799759f9801137f665dbedda2c0815f1bf6f1b 2], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b6f2fcbcfca9db2bd7aa24940224fcd3bbdbb8aa 3], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=189d3c4a94ef19fca2a71a6a336e9fda900e25e7 4], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=76f1418b485da2707531178e517bbb5cf06b3c76 5], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a42dde04152750426cc620fd277e80fffae2f65a 6)]

1.10. /proc/pid/mountinfo

The work being done these days in the VFS like per-process namespaces and such is obsoleting some things, like /proc/mounts (which is always a link to /proc/self/mounts). In its current form lacks important information and suffers some problems (see the code link). 2.6.26 introduces /proc/PID/mountinfo which addresses these deficiencies. Information about the information that can be found on these new files is explained in the commit links.

Code: [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6092d048183b76bfa3f84b32f8158dd8d10bd811 (commit 1], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9d1bc60138977d9c79471b344a64f2df13b2ccef 2], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=73cd49ecdde92fdce131938bdaff4993010d181b 3], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=719f5d7f0b90ac2c8f8ca4232eb322b266fea01e 4], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a1a2c409b666befc58c2db9c7fbddf200f153470 5], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2d4d4864ac08caff5c204a752bd004eed4f08760 6], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=97e7e0f71d6d948c25f11f0a33878d9356d9579e 7)]

1.11. Generic semaphores

Since the introduction of mutexes, semaphores are no longer performance-critical, so the old architecture-specific (and often asm-handcoded) implementation has been reemplaced by a generic one written in C for maintainability, debuggability and extensibility. It removes 7365 LoC

Code: [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=64ac24e738823161693bf791f87adc802cf529ff (commit)]