- About Us
The opening day of the 9th annual Ottawa Linux Symposium (OLS) began with Jonathan Corbet, of Linux Weekly News and his now familiar annual Linux Kernel Report, and wrapped up with a reception put on by Intel where they displayed hardware prototypes for upcoming products.
Corbet's opening keynote began with a very brief history of Linux, showing the kernel release cycle since it was started in 1991. He made the point that the kernel has gone from a significant release every couple of years to one every couple of months over the last few years, with every point release of the kernel being a major release. Today, every point release has new features and API changes.
The release cycle today is very predictable, says Corbet, with kernel 2.6.22 anticipated in July and 2.6.23 expected around October. The cycle starts with a kernel, say 2.6.22-rc1, then a second release candidate is made available, and a third (if necessary), and so on until the release candidate becomes stable, and work begins on the next kernel.
Each kernel release cycle has a 2 week merge period at the start where new features and changes are introduced culminating in the release of -rc1, or release candidate 1, followed by an 8-12 week period of stabilization of the kernel with its new features. At the end of this process the new stable version of the kernel is released.
This release cycle system, explained Corbet, was introduced with the 2.6.12 kernel and the discipline within the kernel development community was established within a few releases. He demonstrated this with a graph showing the number of cumulative lines changed in the kernel over time and kernel version numbers which clearly showed a linear pattern of line changes evolving into a kind of stair case of kernel line change rates.
Since kernel 2.6.17 from June of 2006, Corbet reported, two million lines of kernel code have changed with the help of 2,100 developers in 30,100 change sets.
This release process, Corbet says, moves changes quickly out to the users. Where it used to take up to two or three years for new features to be introduced to the stable kernel, it can now take just a few months. This also allows Linux distributors to keep their distributions closer to the mainline kernel. Under the old kernel development model, Corbet continued, some distributions' kernels included as many as 2000 patches against the mainline kernel. With the rapid release cycle, distributions no longer have any significant need to diverge from the mainline kernel.
But it's not all perfect. Corbet noted that among the things that is not working well is bug tracking, regression testing, documentation, and fixing difficult bugs. Some bugs require the right hardware in the right conditions at the right phase of the moon to solve, he commented. As a result, kernels are released with known bugs still in place.
What's being done to address this? Better bug tracking, stabilization (debugging)-only kernel releases, and automatic testing are a few of the tactics Corbet listed. Things in the kernel are getting better over all, he says.
Corbet continued with his predictions for the future of the kernel with the disclaimer that these are only his opinions of what is to come. First, Corbet says the soon-to-be released 2.6.22 kernel will include a new mac80211 wireless stack, UBI flash-aware volume management, IVTV video tuner drivers, a new CFQ/IO stack, a new FireWire stack, eventfd() system calls, and a SLUB allocator.
On the future of scalability, Corbet says that today's supercomputer is tomorrow's laptop. Linux' 512 processor support works well, he says, but the 4096 processor support still needs some work. The other side of scalability, such as operating on cell phones, Corbet noted, is less well represented in the kernel than its super-computing counterparts.
Corbet says that filesystems are getting bigger, but they are not getting any faster. As drives and filesystems continue to expand, the total time needed to read an entire disk continues to go up. Most filesystems currently are reworks of 1980s Unix filesystems, he went on, and may need redoing.
Among the changes he predicted in the land of the filesystems is a smarter fsck that only scans the parts of the drive that were in use. Corbet says that a new filesystem that just came out in the last few weeks called btrfs is extents based, supports sub-volumes and snapshotting, checksums, and allows on-line fsck. Off-line fsck is very fast in it by design, says Colbert, noting that btrfs is far from stable.
The Ext4 filesystem, the successor to the current Linux Ext3 filesystem, should be coming out soon, says Corbet. It will feature the removal of the 16TB file filesystem limit with 48 bit blocks, extents, nanosecond timestamps, pre-allocation, and checksummed journals.
The Reiser4 filesystem, the successor to ReiserFS, has stalled, says Corbet, with Hans Reiser no longer able to work on it. To move forward, Corbet says that Reiser4 needs a new champion.
The last filesystem Corbet mentioned is LogFS, a flash-oriented filesystem with n-media directory trees.
Virtualisation is becoming more than just a way to get money from venture capitalists, joked Corbet. Xen is getting commercial development and may finally end up in the mainline kernel tree in 2.6.23. He also mentioned Lguest and KVM, the latter a full Virtualisation system with hardware support and working live migration that was merged into the kernel in 2.6.20 although it is still stabilizing.
Corbet also brought up containers, a lightweight virtualisation system in which all guests share one kernel. Several projects are working on this, he says, but noted that they must all work together as multiple container APIs would not work.
Next, Corbet predicted new changes to CPU scheduling, a problem once believed solved, with the introduction of the Completely Fair Scheduler (CFS), which, as Corbet put it, dumps complex heuristics and allocates CPU time in a very simple fairness algorithm. He says he expects this possibly in kernel 2.6.23.
Corbet also says he foresees progress with threadlets, or asynchronous system calls. If a system call blocks, the process will continue on a new thread and pick up the results from the blocked system call later. Among the other places he predicted change was in the realm of power management, video drivers, and tracing, with the help of soon-to-come utrace, an in-kernel tracer.
Last but certainly not least, Corbet says that the Linux kernel is not likely to go to version 3 of the GPL owing to the fact that the entire Linux kernel is explicitly licensed under version 2 of the GPL -- so even if the will develops to relicense it, it would be difficult.
The next talk I went to was by Josef Sipek entitled "Kernel Support for Stackable File Systems." Briefly, Sipek explained what stackable filesystems are and how they work in some rather extensive detail and discussed improvements on the way.
They're called stackable filesystems because several of these can be stacked together on top of one actual filesystem to give the filesystem additional functionality.
A stackable filesystem is a virtual filesystem layer that wraps around a filesystem. Sipek listed a number of examples with largely self-explanatory names of stackable filesystems. Among them, ecryptfs, a stacked filesystem layer that encrypts data on its way to the actual filesystem, gzipfs, a filesystem that compresses data, unionfs, a filesystem that combines multiple filesystems, replayfs, a stacked filesystem that can replace calls to the actual file system to assist with debugging, and a number of others.
At the end of the day, Intel held its annual reception in an upstairs room with free food and alcohol. The company used to provide speakers during this event as well, but as they did last year, this year an Intel employee rose to announce that there would be no speeches, just a technology demonstration in the corner of some of the company's latest. He thanked those at OLS for their continued important work and the notion of free alcohol with no speakers washed over well with enthusiastic applause.
At their technology desk I found an interesting looking device designated the ZI9, a soon-to-be announced prototype of a mobile Internet device measuring a bit over 4 inches across by a bit over 6 inches long. By the time I got to it the battery was dead, but it looked like a cross between a Blackberry, and a tablet laptop.
The device had a miniature keyboard and a large monitor on a swivel to cover the keyboard or operate as a useful monitor, as well as a small camera on a skewer across the top of the device. This device is apparently designed to run Linux.
OLS continues through Saturday, June 30th. We'll have additional reports throughout the week.