Proceedings of the Linux Symposium Volume One July 19th–22nd, 2006 Ottawa, Ontario Canada Contents Enabling Docking Station Support for the Linux Kernel 9 Kristen Carlson Accardi Open Source Graphic Drivers—They Don’t Kill Kittens 19 David M. Airlie kboot—A Boot Loader Based on Kexec 27 Werner Almesberger Ideas on improving Linux infrastructure for performance on multi-core platforms 39 Maxim Alt A Reliable and Portable Multimedia File System 57 J.-Y. Hwang, J.-K. Bae, A. Kirnasov, M.-S. Jang, & H.-Y. Kim Utilizing IOMMUs for Virtualization in Linux and Xen 71 M. Ben-Yehuda, J. Mason, J. Xenidis, O. Krieger, L. Van Doorn, J. Nakajima, A. Mallick, & E. Wahlig Towards a Highly Adaptable Filesystem Framework for Linux 87 S. Bhattacharya & D. Da Silva Multiple Instances of the Global Linux Namespaces 101 Eric W. Biederman Fully Automated Testing of the Linux Kernel 113 M. Bligh & A.P. Whitcroft Linux Laptop Battery Life 127 L. Brown, K.A. Karasyov, V.P. Lebedev, R.P. Stanley, & A.Y. Starikovskiy The Frysk Execution Analysis Architecture 147 Andrew Cagney Evaluating Linux Kernel Crash Dumping Mechanisms 153 Fernando Luis Vázquez Cao Exploring High Bandwidth Filesystems on Large Systems 177 Dave Chinner & Jeremy Higdon The Effects of Filesystem Fragmentation 193 Giel de Nijs, Ard Biesheuvel, Ad Denissen, Niek Lambert The LTTng tracer: A low impact performance and behavior monitor for GNU/Linux 209 M. Desnoyers & M.R. Dagenais Linux as a Hypervisor 225 Jeff Dike System Firmware Updates Utilizing Sofware Repositories 235 Matt Domsch & Michael Brown The Need for Asynchronous, Zero-Copy Network I/O 247 Ulrich Drepper Problem Solving With Systemtap 261 Frank Ch. Eigler Perfmon2: a flexible performance monitoring interface for Linux 269 Stéphane Eranian OCFS2: The Oracle Clustered File System, Version 2 289 Mark Fasheh tgt: Framework for Storage Target Drivers 303 Tomonori Fujita & Mike Christie More Linux for Less 313 Michael Hennerich & Robin Getz Hrtimers and Beyond: Transforming the Linux Time Subsystems 333 Thomas Gleixner and Douglas Niehaus Making Applications Mobile Under Linux 347 C. Le Goater, D. Lezcano, C. Calmels, D. Hansen, S.E. Hallyn, & H. Franke The What, The Why and the Where To of Anti-Fragmentation 369 Mel Gorman and Andy Whitcroft GIT—A Stupid Content Tracker 385 Junio C. Hamano Reducing fsck time for ext2 file systems 395 V. Henson, Z. Brown, T. T’so, & A. van de Ven Native POSIX Threads Library (NPTL) Support for uClibc. 409 Steven J. Hill Playing BlueZ on the D-Bus 421 Marcel Holtmann FS-Cache: A Network Filesystem Caching Facility 427 David Howells Why Userspace Sucks—Or 101 Really Dumb Things Your App Shouldn’t Do 441 Dave Jones Conference Organizers Andrew J. Hutton, Steamballoon, Inc. C. Craig Ross, Linux Symposium Review Committee Jeff Garzik, Red Hat Software Gerrit Huizenga, IBM Dave Jones, Red Hat Software Ben LaHaise, Intel Corporation Matt Mackall, Selenic Consulting Patrick Mochel, Intel Corporation C. Craig Ross, Linux Symposium Andrew Hutton, Steamballoon, Inc. Proceedings Formatting Team John W. Lockhart, Red Hat, Inc. David M. Fellows, Fellows and Carr, Inc. Kyle McMartin Authors retain copyright to all submitted papers, but have granted unlimited redistribution rights to all as a condition of submission. Enabling Docking Station Support for the Linux Kernel Is Harder Than You Would Think Kristen Carlson Accardi Open Source Technology Center, Intel Corporation [email protected] Abstract and lighter, more vendors are seeking to replace functionality that used to be built into the lap- top with a docking station. Commonly, docking Full docking station support has been a feature stations will provide additional USB ports, PCI long absent from the Linux kernel—for good slots, and sometimes extra features like built in reason. From ACPI to PCI, full docking sta- media card readers or Ethernet ports. Most ven- tion support required modifications to multiple dors seem to be marketing them as space saving subsystems in the kernel, building on code that devices, and as an improved user experience for was designed for server hot-plug features rather mobile users who do not wish to manage a lot than laptops with docking stations. This paper of peripheral devices. will present an overview of the work we have done to implement docking station support in the kernel as well as a summary of the techni- We embarked on the docking station project for cal challenges faced along the way. a few reasons. Firstly, we knew there were a few members of the Linux community out there We will first define what it means to dock and who actually did use docking stations. These undock. Then, we will discuss a few varia- people would hopefully post to the hotplug PCI tions of docking station implementations, both mailing lists every once in a while, wondering from a hardware and firmware perspective. Fi- if some round of I/O Hotplug patches would en- nally, we will delve into the guts of the soft- able hot docking to work. Secondly, there was ware implementation in Linux—and show how a need to be able to implement a couple sce- adding docking station support is really harder narios that dock stations provide a convenient than you would think. test case for. Many dock stations are actually Peer-to-peer bridges with a set of buses and de- vices located behind the bridge. Hot add with 1 Introduction and Motivation devices with P2P bridges on them had always been hard for us to test correctly due to lack of devices. Also, the ACPI _EJD method is com- It’s no secret that people have not been clam- monly used in AML code for docking stations, oring for docking station support. Most peo- but this method can also be applied to any hot- ple do not consider docking stations essential, pluggable tree of devices. Finally, we felt that and indeed some feel they are completely un- with the expanding product offerings for dock necessary. However, as laptops become thinner stations, filling this feature gap would eventu- 10 • Enabling Docking Station Support for the Linux Kernel ally become important. Device (DOCK1) { Name(_ADR, . ) Method(_EJ0, 0) {. } Method(_DCK, 1) {. } 2 Docking Basics } There are three types of docking that are de- Figure 1: Example DSDT that defines a Dock fined. Device When the user places their system into the • Cold Docking/Undocking Laptop is docking station, the OS will be notified with an booted attached to the dock station. interrupt, and the platform will send a Device Laptop is powered off prior to removal Check notify. The notify will be sent to a no- from the dock station. This has always tify handler and then that handler is responsible been supported by Linux. The devices on for calling the _DCK control method with the the dock station are enumerated as if they proper arguments to engage the dock connec- are part of the laptop. tor. • Warm Docking/Undocking Laptop is _DCK as defined in the ACPI specification booted either docked or undocked. Sys- is shown in Figure 2. Assuming that _DCK tem is placed into a suspend state, and then returned successfully, the OS must now re- either docked or undocked. This may be enumerate all enumerable buses (PCI) and also supported by Linux, assuming that your all the other devices that may not be on enumer- laptop actually suspends. It depends really able buses that are on the dock. on whether a driver’s resume routine will rescan for new devices or not. Undocking is just like docking, only in reverse. When the user hits the release button on the • Hot Docking/Undocking Laptop is docking station, the OS is notified with an eject booted outside the dock station. Laptop is request. The notify handler must first execute then inserted into the dock station while _DCK(0) to release the docking connector, and completely powered and operating. This then should execute the _EJ0 method after re- has recently had limited support, but only moving all the devices that are on the docking with a platform specific ACPI driver. station from the OS. Hotplugging new devices on the dock station has never been supported. The _DCK method is not only responsible for engaging the dock connector, it seems to also be a convenient place for system manufacturers Docking is controlled by ACPI. ACPI defines to do device initialization. This is all imple- a dock as an object containing a method called mentation dependent. I have seen _DCK meth- _DCK. An example dock device definition is ods that do things such as programming a USB shown in Figure 1. host controller to detect the USB hub on the dock station, issuing resets for PCI devices, and _DCK is what ACPI calls a "control method". even attempting to modify PCI config space to Not only does it tell the OS that this ACPI ob- assign new bus numbers1 to the dock bridge. ject is a dock, it also is used to control the iso- lation logic on the dock connector. 1Highly unacceptable behavior 2006 Linux Symposium, Volume One • 11 This control method is located in the device object that represents the docking station (that is, the device object with all the _EJx control methods for the docking station). The presence of _DCK indicates to the OS that the device is really a docking station. _DCK also controls the isolation logic on the docking connector. This allows an OS to prepare for docking before the bus is activated and devices appear on the bus [1]. Arguments: Arg0 1 Dock (that is, remove isolation from connector) 0 Undock (isolate from connector) Return Code: 1 if successful, 0 if failed.