Interesting things can be seen by looking at the the people who attend an event like this one. Not that long ago, the preferred attire was a shirt from a Linux event - the older, the better. While those shirts are still very much in evidence, shirts of the button-down variety are on the rise. Fortunately, there are still very few neckties to be seen (James Bottomley - next year's OLS keynote speaker - being the exception that proves the rule in this regard). There were also quite a few attendees who had clearly made the trip from Asia.
LinuxWorld may be the place to go to see what companies are doing, but OLS has clearly established itself as the event to attend to learn about what the development community - and the kernel development community in particular - is up to.
This year's schedule reveals some things about what the community is interested in. Virtualization remains a hot topic, but the emphasis has changed: Xen, the king of paravirtualization, was well represented, but was far from the whole story. Ian Pratt's Xen talk was held in one of the smaller rooms this year. The hotter topic appeared to be containers - lightweight virtualization which runs under the same kernel as the host. There is a lot of development activity around containers at the moment, and many of the people involved were at OLS to talk about it.
Last year's schedule featured exactly one filesystem talk - an update on ext3. This year, a quick scan shows no less than nine filesystem talks, plus a few on related topics (shared subtrees, for example). Expect to see some interesting development work in the filesystems area in the coming years.
This year's keynote speaker was Greg Kroah-Hartman. Greg has posted the text of his talk along with the slides; it is such a clear representation of what was said that your editor sees no point in writing up a separate summary. The talk covered topics like hardware support (Linux is now second to none, says Greg), the illegal and unethical nature of closed source kernel modules, various aspects of the kernel development process, and more. The talk is very much worth a read.
For those who have not seen the article by Arjan van de Ven mentioned in Greg's talk: Arjan's doomsday scenario is also worth reading.
For the curious, the slides from LWN editor Jonathan Corbet's talk are available.
OLS has always been a kernel-oriented event, and the 2006 version was perhaps the most kernel-heavy yet. A look at the schedule shows almost no non-kernel talks - and most of the exceptions were concerned with the git and mercurial source control systems. The Desktop Developers' Conference was held immediately before OLS (at the same time as the Kernel Summit), but speakers from that conference did not speak at OLS. Their presence was very much felt, however, and there were some good conversations held between developers responsible for various levels of the full Linux system. Next year, however, it would be nice to hear more from the desktop people at OLS.
The fact that such a small complaint is the first that comes to mind speaks loudly. OLS remains a top-notch technical conference with interesting speakers, good organization (even the traditionally late final keynote almost started on time this year), great conversations, and a murderous closing party. The annual Ottawa pilgrimage remains an important event for many in the development community.Why user space sucks," was certain to be popular at a setting like this. So many of the people in the standing room only crowd might well have wondered why this talk was not scheduled into the larger room. Perhaps the powers that be feared that a non-kernel talk would not have a large audience - even when it is given by a well-known kernel hacker.
Dave set out to reduce the time it took his Fedora system to boot. In an attempt to figure out what was taking so long, he instrumented the kernel to log certain basic file operations. As it turned out, the boot process involved calling stat() 79,000 times, opening 27,000 files, and running 1382 programs. That struck him as being just a little excessive; getting a system running shouldn't require that much work. So he looked further. Here are a few of the things he found:
There were more examples, and members of the audience had several more of their own. It was all great fun; Dave says he takes joy in collecting train wrecks.
The point of the session was not (just) to bash on particular applications, however. The real issue is that our systems are slower than they need to be because they are doing vast amounts of pointless work. This situation comes about in a number of ways; as applications become more complex and rely on more levels of libraries, it can be hard for a programmer to know just what is really going on. And, as has been understood for many years, programmers are very bad at guessing where the hot spots will be in their creations. That is why profiling tools so often yield surprising results.
Programs (and kernels) which do stupid things will always be with us. We cannot fix them, however, if we do not go in and actually look for the problems. Too many programmers, it seems, check in their changes once they appear to work and do not take the time to watch how their programs work. A bit more time spent watching our applications in operation might lead to faster, less resource-hungry systems for all of us.GNU Compiler Collection (GCC) is a fundamental part of our free operating system. Licenses may make the software free, but it's GCC which lets us turn that software into something our computers can run. GCC's strengths and weaknesses will, thus, influence the quality of a Linux system in a big way. GCC is, however, an opaque tool for many Linux users - and for many developers as well. It is a black box, full of compiler magic, which, one hopes, just works. For those interested in looking a little more deeply into GCC, however, Diego Novillo's OLS talk was a welcome introduction.
According to Diego, GCC has been at a bit of a turning point over the last couple of years. On one hand, the software is popular and ubiquitous. On the other, it is a pile of 2.2 million lines of code, initially developed by "people who didn't know about compilers" (that comment clearly intended as a joke), and showing all of its 15 years of age. The code is difficult to maintain, and even harder to push forward. Compiler technology has moved forward in many ways, and GCC is sometimes having a hard time keeping up.
The architecture of GCC has often required developers to make changes throughout the pipeline. But the complexity of the code is such that nobody is really able to understand the entire pipeline. There are simply too many different tasks being performed. Recent architectural improvements are changing that situation, however, providing better isolation between the various pipeline stages.
GCC has a steering committee for dealing with "political stuff." There is, at any given time, one release manager whose job is to get the next release together; it is, says Diego, a thankless job. Then, there is a whole set of maintainers who are empowered to make changes all over the tree. The project is trying to get away from having maintainers with global commit privileges, however. Since building a good mental model of the entire compiler is essentially impossible, it is better to keep maintainers within their areas of expertise.
The (idealized) development model works in three stages. The first two months are for major changes and the addition of major new features. Then, over the next two months, things tighten down and focus on stabilization and the occasional addition of small features. Finally, in the last two months, only bug fixes are allowed. This is, Diego says, "where everybody disappears" and the release manager is force to chase down developers and nag them into fixing bugs. Much of the work in this stage is driven by companies with an interest in the release.
In the end, this ideal six-month schedule tends to not work out quite so well in reality. But, says Diego, the project is able to get "one good release" out every year.
GCC development works out of a central subversion repository with many development branches. Anybody wishing to contribute to GCC must assign copyrights to the Free Software Foundation.
The compiler pipeline looks something like this:
The effect of recasting GCC into the above form is a compiler which is more modular and easier to work with.
Future plans were touched on briefly. There is currently a great deal of interest in static analysis tools. The GCC folks would like to support that work, but they do not want to weigh down the compiler with a large pile of static analysis tools. So they will likely implement a set of hooks which allow third party tools to get the information they need from the compiler. Inevitably, it was asked what sort of license those tools would need to have to be able to use the GCC hooks; evidently no answer to that question exists yet, however.
Another area of interest is link-time optimization and the ability to deal with multiple program units as a whole. There is also work happening on dynamic compilation - compiling to byte codes which are then interpreted by a just-in-time compiler at run time. Much more information on current GCC development can be found on the GCC wiki.
This session was highly informative. Unfortunately, its positioning on the schedule (in the first Saturday morning slot, when many of those who participated in the previous evening's whiskey tasting event were notably absent) may have reduced attendance somewhat. This was, however, a talk worth getting up for.
Page editor: Jonathan Corbet
Copyright © 2006, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds