The 2005 Linux Kernel Developers' Summit

The 2005 version of the invitation-only Linux Kernel Developers' Summit was held on July 18 and 19 in Ottawa. The following are LWN editor Jonathan Corbet's notes from the discussion.

July 18 sessions:

• The processor panel, being a discussion between the kernel developers and processor architects from AMD, IBM, and Intel.

• I/O Buses, and I/O memory management units in particular.

• Virtual memory topics, including fragmentation, response to memory pressure, and scalability.

• ExecShield; Red Hat's security patches which have only partially been merged into the mainline.

• Virtualization, and how the kernel can better support it.

• The virtual filesystem, and various topics related to the VFS.

July 19 (Tuesday) sessions:

• The hardware vendors' panel, on the impedance mismatch between the kernel development community and manufacturers.

• Report from the networking summit which was held before the kernel event.

• The convergence of storage and network paths; how do you ensure safe operation when distinction between the networking and block subsystems blurs?

• Clustering: a brief report from the clustering summit held two weeks before in Germany.

• RAS tools, being mostly a discussion of the recently merged kexec and kdump capabilities.

• Realtime capabilities, a look at the various proposals for implementing realtime response with Linux.

• The kernel and the Linux desktop; a report from the Desktop Developers' Conference.

• A report from the power management summit, contributed by Pat Mochel. Pat also led the session at the Kernel Summit on power management. The one thing that session added which is not in Pat's report: Linus took the power management developers to task for focusing on suspend-to-disk capabilities, when, he says, what everybody wants is suspend-to-RAM. The latter is complicated, however, by the usual video adapter difficulties.

• The kernel development process, with an emphasis on how the community could produce kernels with fewer bugs.

The group photo is available in medium resolution (1024 pixels) and full resolution (3072 pixels) formats.

Index entries for this article
Kernel	Kernel Summit
Conference	Kernel Summit/2005

---

to post comments

Thanks for the pixels

Posted Jul 20, 2005 5:55 UTC (Wed) by ncm (guest, #165) [Link] (2 responses)

My aging eyes thank you for the hi-res image. Was Iñaky Perez Gonzalez there? I'm not sure I'd recognize him any more. (Hi Iñaky, sorry for losing touch.)

Where I can rant and whine on Linus Torvals?

Posted Aug 23, 2007 1:02 UTC (Thu) by marraco (guest, #46950) [Link] (1 responses)

I need to shake Linus to make him include kernel support for multiple mouses and multiple keyboards.

We have today multiple monitor. That way you can use two monitors, but I need to give the second monitor to other people, give them the second keyboard and mouse, and have many users on one machine.

I can do that today, only in windows, using BetWin. But I can´t make it in Linux, and kernel developpers are guilty.

I just would love to stalk kernel developpers, and cry "do THAT. DO THAT".

Microsoft do not want to do it, because it would make for less OS licenses sold.
If you have little money, you can pirate Windows XX, but you cannot pirate hardware. So Linux being free is not a massive real world money saving, but supporting many users on one computer (in the real world, not for deep hacker geeks) would make linux a deep money saving choice... And Microsoft can´t match it.

Kernel Does Support Many Input Devices

Posted Aug 23, 2007 2:08 UTC (Thu) by zlynx (guest, #2285) [Link]

The kernel is not the problem here. The problem is your configuration of the X server.

My laptop has seven input devices listed by the kernel. The built-in keyboard, the trackpad, the external USB keyboard and mouse and various special buttons.

I configure X to use all of these on one display, but X could also be configured to run different servers with different input devices for each server.

Try copying your /etc/X11/xorg.conf to a new filename, change its Input sections, and run a second X server on virtual terminal 8 using the new config file.

As for console sessions, I don't remember the name of the program, but you use the same trick with framebuffer displays and a user-space console manager. The manager program reads input from the specified devices and draws it to the framebuffer. A full-screen xterm makes more sense to me though.

The 2005 Linux Kernel Developers' Summit

Posted Jul 20, 2005 8:09 UTC (Wed) by cborni (subscriber, #12949) [Link] (4 responses)

I totally agree with Linus. I absolutely dont care about suspend to disk I
want suspend to ram. To make things worse, lots of new kernel features
like freeing memory before suspend or compression might be a good idea for
the first, but are useless for the latter.
Then there is ACPI, which is unfortunately not a simple design. Some month
ago I tried to fix some kernel warnings about sleeping functions, but I
was told that the right solution is much harder and requires some
redesign. So its a long way to go I guess.
Even if we are able to get the kernel code in shape, lots of users will
probably use the nvidia/ATI/whatever binary module which need to be fixed
as well.

The 2005 Linux Kernel Developers' Summit

Posted Jul 20, 2005 10:13 UTC (Wed) by arafel (subscriber, #18557) [Link] (1 responses)

Unfortunately, I don't think Linus is right. I don't want suspend to RAM, I want suspend to disk.

Well, okay, both might be useful - but if I can only have one, it'll be disk.

The 2005 Linux Kernel Developers' Summit

Posted Jul 21, 2005 11:58 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link]

Why not stage in RAM, and optionally store to disk? Might be a compression opportunity there. I don't grasp the OR here.

Suspend to Disk/RAM

Posted Jul 20, 2005 17:34 UTC (Wed) by danm628 (guest, #5995) [Link] (1 responses)

I suspect many people want what I can get from XP on my work notebook (IBM Thinkpad T40). When the lid is shut it does a suspend to RAM, when the lid is opened the system comes up within a couple of seconds. When the system stays in suspend to RAM for a period (I have it set to 15 minutes) it wakes up and does a suspend to disk. I go for weeks without shutting down and rebooting my work notebook. (Actually it can't go for weeks without a reboot, since there will be at least one patch pushed by IT which requires a reboot.)

My home notebook (Thinkpad T41) running Ubuntu isn't quite as flexible. I can do suspend to RAM but there is no option to automatically suspend to disk after staying in suspend to RAM for a period. (Or if there is an option I didn't find it -- which would be a GUI bug not a kernel issue.) Suspend to disk works and it is what I normally do, that way the system comes up fairly quickly when I want to use it. Windows is a *LOT* prettier to watch come out of suspend to disk. I don't mind the odd screen flashes, etc. while the display driver. But I'm sure my non-programmer friends would prefer a nice progress bar instead of kprintf messages.

So what I really want is both suspend to disk and RAM to work reliably. I want to be able to open my notebook and quickly get to work, the definition of quickly depends on how long the notebook has been off (couple of seconds for suspend to RAM or 10 to 20 seconds for suspend to disk). I like being able to shut the lid and know that the system will automatically go to the appropriate low power state. I don't want to have to decide how long I'm going to want it to suspend for and which type of suspend it should do.

Suspend to Disk/RAM

Posted Jul 22, 2005 20:44 UTC (Fri) by zblaxell (subscriber, #26385) [Link]

If you have working suspend-to-RAM, suspend-to-disk, and ACPI wakeup (echo YYYY-MM-DD HH:MM:SS > /proc/acpi/alarm), it is possible to have the machine arrange to wake itself up in 15 minutes, then suspend to RAM. On resume from RAM, the machine checks the clock and decides to either finish resuming, or suspend to disk. I know this works because I've configured my ex-laptop to do it...but I stopped because the laptop was more often than not in a moving insulated laptop case 15 minutes after suspend, and the CPU would sometimes cook itself in the ~45 seconds required to suspend to disk, especially in summer.

I'd like to see an LVM with a snapshot feature combined with suspend-to-disk, to implement a checkpoint-restart system, with the option of reverting the entire system (RAM and disk) to where it was when it last suspended. The relatively minor data loss of reverting to last suspend before a crash is usually much less painful than reconstructing all the userspace state by hand (literally).

Once the suspend/resume problem is solved, the next most annoying thing about laptops is the game of Russian roulette that is played every time a PCMCIA or USB device is connected. It's especially bad for laptops since they are exposed to more devices per boot than a typical desktop in my experience. If a device with a buggy Linux driver crashes on load, it usually takes the system with it. A checkpoint/restart approach would allow the user to say "oops, guess I'll unplug that and try again" instead of "darn, now I have to spend 20 minutes getting all my user-space stuff put back together."

The 2005 Linux Kernel Developers' Summit

Posted Jul 31, 2005 0:46 UTC (Sun) by Nir (guest, #27440) [Link]

why not tell us the names of all the developers ? i want to know who is who ?

The 2005 Linux Kernel Developers' Summit

Posted Aug 16, 2005 23:47 UTC (Tue) by meonkeys (guest, #31871) [Link] (1 responses)

Just curious, how many women are in that photo?

The 2005 Linux Kernel Developers' Summit

Posted Nov 8, 2005 16:42 UTC (Tue) by newport (guest, #33705) [Link]

3 if you include the guy with the pink bow tie.