Looking ahead to Kernel Summit 2007

Virtualization is the hot topic in the Linux business, but it's off the developers' agenda. Here's what kernel developers are planning to discuss at their upcoming conference in Cambridge.

By Jonathan Corbet, LinuxWorld.com, 08/28/07

 Start a discussion    Print article

 Comments (1)    Print article

For the past several years, the annual, invitation-only kernel developers' summit has been held immediately prior to the Ottawa Linux Symposium. This year is different, though: the summit is, instead, happening just after LinuxConf Europe in Cambridge, UK. As usual, the author will be there and will be able to report from the event. The preliminary agenda has been posted, though, as has the list of attendees [PDF]. So it is possible to look forward and get a sense for what is likely to be discussed.

A few months ago, a discussion of interesting topics was held on the 2007 summit list. Many of the usual topics came around; there is always plenty of interesting development work going on in the kernel community. Andrew Morton objected to many of the topics under discussion, though, saying that the summit was not the appropriate venue to talk about them:

My overall take on kernel summit: we spend far too much time talking about technical stuff. There is little benefit in doing this: we conduct technical discussions over email and we do it well, and there are many very good reasons for doing it that way.... We fly halfway around the world to yap on about dentry cache scalability? Spare me, we'd get more done by staying home.

Andrew's conclusion, which was seconded by a number of other developers, was that the process-oriented discussions are always more interesting and useful than the deep technical sessions. Discussions of virtualization, memory management, or device drivers will always be uninteresting to a significant part of the group, and they do not necessarily add much over what can be done with email. But the process-oriented talk affects everybody and is much harder to do electronically.

So this year's agenda is more high-level than in previous year. That does not mean that there will be no technical talk, though. Some of the more technical sessions will cover:

• Reports from mini-summits. The kernel is a big program, and developers often find that subsystem-specific questions are better addressed in smaller groups. At the summit, attendees from some recent mini-summits (covering power management, filesystems, storage, and virtualization, at least) will report back to the larger group.

   

• Real time and scheduler issues are on the agenda because there are some big decisions to make. While much of the real-time tree has found its way into the mainline, some of the more disruptive chunks (sleeping spinlocks, threaded interrupt handlers) remain outside. Also outside of the mainline is the syslets/threadlets patch set. Hopefully some decisions will be made on whether these features should be merged, and, if so, what needs to be done to get them into shape.

   

• There are a number of memory management issues out there, including the variable page and variable block size patches, approaches to deadlock avoidance, scalability work, and more. Also on the agenda is the more process-oriented question of why memory management patches are so hard to get into the mainline.

   

• Virtualization has fallen off the agenda because most of the kernel-level work in this area has already been merged. The containers developers are just getting going, though, and there are a lot of questions about what their final destination is thought to be. A full containers implementation could impose significant overhead - on developers and on run-time performance - and could prove hard to sell.

That's about it for the serious technical talks; everything else will have a higher-level focus. The summit will start with a panel of distributor kernel maintainers. To a great extent, distributors are the immediate customers for the kernels that the developers put out; those distributors are then charged with getting mainline releases into a condition that allows it to be shipped to users. Distributor kernel maintainers tend to be on the front line when things go wrong; they always hear about all the problems. This panel will be a chance for those maintainers to talk about the quality of the kernels they are getting from the mainline and how things could be made to work better.

Once upon a time, the kernel stood alone and presented services to the system by way of the system call interface. In current systems, instead, users see a view of the system which is created by a whole set of utilities, including the C library, udev, HAL, and more. Interactions between these low-level components and the kernel is not always as smooth as it could be, and, despite the best efforts of the kernel development community, kernel releases have been known to occasionally break utilities like udev. The "greater kernel ecosystem" session will cover these issues and the general question of making the system as a whole work better together. Establishing better control over the user-space API is likely to come up, though the problem remains difficult.

Featured Whitepapers

About Us | Contact Us | Advertising Info | Terms of Service/Privacy

Copyright, 2006-2007 Network World, Inc. All rights reserved.