2009 09/03/2009 06/06/2009 28 This talk provides an overview of the requirements, challenges, and progress of bringing the promise of the Simplified Mandatory Access Contorl Kernel (Smack) to user space. The talk uses a well known commercial application as an example of both how using Smack can add value and how it can be done. The talk covers modest changes that make applciations more friendly in a Smack environment. Additionally, the implications of adding Smack support to the Xorg server as a policy enforcing application are covered. There is a brief overview of Smack and its design goals to ensure no one gets lost. This includes Mandatory Access Control, Smack interfaces, and the security model. Networking receives special attention due to the importance it plays in application deployment. 06/06/2009 2009 09/02/2009 06/14/2009 47 One of the compelling features of the OpenFirmware design is that it makes a structured description of the hardware called the "device tree" available to the operating system. The operating system reads the device tree and uses it to figure out such things like how much memory is available, bus layout, list of devices, and how interrupts are connected. By encoding the platform layout in hardware, it removes the requirement to hardcode all known board configurations into the kernel itself, a pattern which is common in the embedded Linux world. The data structure is useful enough that a decision was made to require all PowerPC platforms to pass a device tree to the Linux kernel at boot time and the Flattened Device Tree (FDT) data format was developed for providing a device tree on systems without OpenFirmware (ie. almost every embedded PowerPC). See this paper for a detailed description of the switch to FDT for embedded PowerPC platforms, and a discussion of the tradeoffs. "http://ols.fedoraproject.org/OLS/Reprints-2008/likely2-reprint.pdf":http://ols.fedoraproject.org/OLS/Reprints-2008/likely2-reprint.pdf Other architectures also make use of the FDT data format. The Microblaze arch requires an FDT to be passed at boot time, and some out-of-mainline ARM and MIPS board ports use it too. In this session we will discuss the possibility of making the Flattened Device Tree data structure available as a 'stock' method for describing hardware for platforms which don't already have a firmware interface for describing configuration (in particular embedded non-x86). We will discuss how to manage and standardize data format of for new types of devices, impact (or lack thereof) on firmware, and work needed to make FDT infrastructure available on all architectures. Goal of session is to coordinate FDT development and make decisions about how common FDT support should be organized in the kernel. 06/14/2009 2009 09/04/2009 06/22/2009 85 Existing approaches to concurrent programming often fail to account for synchronization costs on modern shared-memory multiprocessor architectures. A new approach to concurrent programming, known as relativistic programming, can reduce or in some cases eliminate synchronization overhead on such architectures. This approach avoids the costs of inter-processor communication and memory access by permitting processors to operate from a relativistic view of memory provided by their own caches, rather than from an absolute reference frame of memory as seen by all processors. This research shows how relativistic programming techniques can provide the perceived advantages of optimistic synchronization without the useless parallelism caused by rollbacks and retries. Descriptions of several implementations of a concurrent hash table illustrate the differences between traditional and relativistic approaches to concurrent programming. An analysis of the fundamental performance bottlenecks in existing concurrent programming techniques, both optimistic and pessimistic, directly motivates the key ideas of relativistic programming. Relativistic techniques provide performance and scalability advantages over traditional synchronization, demonstrated through benchmarks of concurrent hash tables implemented in the Linux kernel. The demonstrated relativistic hash table makes use of a novel relativistic hash table move operation. 06/22/2009 2009 08/18/2009 06/15/2009 66 Specialized distros, and stripped down default installs have resulted in impressive boot speeds; but what is a bog-standard distro to do? This talk examines some of the gains made to Fedora (and upstream) by improving what is done during boot, and what can be deferred for later. For instance, why do we need to load sound drivers before we have a filesystem mounted read-write? Why do we need cups running without any printers attached? And if you do have a printer, why do you need it before your network is up? When is an appropriate time to start system services? This talk seeks to address some of these questions for the general purpose desktop or laptop machine. 06/15/2009 2009 08/18/2009 04/28/2009 19 We will present the Autotest system, which is capable of controlling thousands of machines simultaneously, as individuals or clusters. Results are automatically published to http://test.kernel.org for every -git snapshot and release, where results from many different contributors can be combined and published. We will cover the motivation for the project - the reasons for doing all testing via an automated system, how this makes developers life easier, not harder, and what kinds of testing this enables. Feedback will also be solicited as to what tests and methods we can run to help the community, and what structural changes people would like to see in Autotest. Autotest is released under the GPL v2 04/28/2009 2009 08/18/2009 06/18/2009 76 User space clustering stack brings advanced and flexible cluster file systems (e.g. OCFS2), which involved in the usage of unified Distributed Lock Manager code in Linux Kernel (a.k.a fs/dlm). This talk intends to invoke the open discussion on (but not limited to) DLM and clustering file system realted issues. For examples, the lock mastering expense, lock communication cost, dlm compatible issue between fs/dlm and OCFS2, deadlocking detection ... 06/18/2009 2009 09/03/2009 06/15/2009 57 Over the last 10 years, a lot of functionality have slowly moved out of the X server and into libraries or kernel drivers. It started with freetype and fontconfig providing an alternative to the core X fonts and direct rendering OpenGL as a graphics driver in a client side library. Then cairo came along and provided a modern 2D rendering library independent of X and compositing managers took over control of the rendering of the desktop. Recently with GEM and KMS in the Linux kernel, we can do modesetting outside X and schedule several direct rendering clients. The end result is a highly modular graphics stack. Wayland is a new display server building on top of all those components. We're trying to distill out the functionality in the X server that is still used by the modern Linux desktop. This turns out to be not a whole lot. Applications can allocate their own off-screen buffers and render their window contents by themselves. In the end, what's needed is a way to present the resulting window surface to a compositor and a way to receive input. This is what Wayland provides, by piecing together the components already in the eco-system in a slightly different way. X will always be relevant, in the same way Fortran compilers and VRML browsers are, but it's time that we think about moving it out of the critical path and provide it as an optional component for legacy applications. 06/15/2009 2009 09/04/2009 06/11/2009 38 KVM is a Linux kernel module that exposes hardware virtualization support to userspace. QEMU is a full system simulator that runs as a user space process and emulates/virtualizes many types of machines including a standard PC. Together, KVM and QEMU enable Linux to act as a hypervisor. As a hypervisor, I/O performance is a weak area today in Linux. Since all I/O for guests are generated from QEMU, we are largely limited by the I/O interfaces provided by the Linux kernel to userspace. The current set of storage I/O interfaces have proven to not map well to QEMU's requirements. This talk will cover how we are currently using the storage I/O interfaces provided by Linux. It will focus on the mechanisms to generate multiple asynchonrous, scatter/gather I/O requests to buffered and non-buffered files along with physical devices. It will also cover topics like request tagging and barriers. The goal of the talk will be to generate discussion about proposed future interfaces (syslets, acalls, etc.) and to discuss whether current interfaces like linux-aio are at all salvagable. Virtualization is perhaps one of the more demanding userspace I/O workloads available so it serves as a particularly good canary in evaluating future I/O interfaces. 06/11/2009 2009 09/03/2009 06/09/2009 29 Today we have several competing technologies with which to build a fully-accelerated cairo backend. Over the last year just a single technology has matured that makes 2D client-side rendering palatable, GEM. By moving the memory management, command scheduling and execution into the kernel, any number of process can co-operate and focus on performing their own rendering via the GPU. cairo-drm-i915 has demonstrated just how easy it is to take an existing EXA driver, implement it as a cairo backend and supercharge its performance. Though people may prefer such work be done in a pixman-drm backend... Then competing against cairo-drm are the various efforts to write a true cairo-gl backend. (glitz's design of implementing XRender on top of OpenGL has proven to be too limiting.) Here people speculate whether interfacing directly with gallium (i.e. cairo being just another state-tracker) will be our panacea. The goal is a fully-accelerated tessellator for high quality 2D interfaces, cairo on the gpu. The question is how? 06/09/2009 2009 08/18/2009 06/14/2009 48 CPUs are now cheap, so it is not surprising to see many embedded system designs containing more than one CPU. Aside from the familiar Symmetric Multiprocessing (SMP) arrangement, many systems use some form of Asymmetric Multiprocessing (AMP) which divides responsibilities between CPUs and runs independent operating system instances on each core. There are many reasons why a system designer may choose and AMP design, but doing so means that none of the available Linux IPC mechanisms are usable between processors. While there are many methods of IPC between CPUs available (serial links, fifos, etc), this session focuses specifically on using shared memory regions for IPC, whether it be CPUs connected via a PCI bus, dual port RAM, or multiple processors sharing the same physical address space (ie. an SMP chip used for AMP). Linux is used in such systems, but mainline kernel doesn't currently contain any infrastructure for supporting shared memory IPC between independent operating system instances. This session is to discuss and debate shared memory IPC in AMP systems. We will discuss the services desired (virtual serial, virtual network, sockets, remote procedure call, etc), the implementation options (virtio pver PCI, TI's DSPLINK, others?), working with non-Linux OS instances, and whether or not it is even feasible to implement a common set of shared memory IPC tools to be merged into the mainline kernel. Participants can and should bring up any real world issues that they are encountering with Linux on Asymmetric Multiprocessing systems. 06/14/2009 2009 09/01/2009 06/22/2009 86 Modern hardware platforms have various error sources, including chipsets, CPUs, memory, PCI-AER and others. Currently all of these (if they are reported) are reported in a ad-hoc fashion to various different log files. This can can make it difficult to write error analysis tools and backends and also cause various other problems. The talk will discuss the pros and cons of a possible unified error reporting method for platform errors and how user space infrastructure for it could look like. This will discuss both existing code, some prototypes and also some pie-in-the-sky. 06/22/2009 2009 08/31/2009 06/15/2009 67 Most Linux plumbers will be aware that the audio environment is a mess. But how did it get to be this way? Because you can't understand the future without understanding the past, this talk will start by examining history of the OSS kernel drivers, how they were replaced by ALSA, and the design assumptions and goals that went into ALSA. I will then talk about early sound servers such as esd and artsd and how these represented an extremely limited conception of what "audio on a computer" meant. Many of the problems faced within the Linux audio environment come from an inadequate understanding of the many different kinds of audio applications that exist, so I will survey the dramatic range of these apps both in terms of use cases and technical requirements, and discuss why solutions like JACK and PulseAudio are so different. I will then leap into the bigger question that arises from a casual glance at OS X - how did Apple "solve" the problems that appear to exist on Linux for audio applications and users, and what can we learn from their approach? Similar consideration will be given to Windows. Finally, I would like to discuss whether the fundamental problem is technical, or political inasmuch as it reflects the federated nature of Linux rather than the heirarchical model of Apple Inc. and Microsoft. 06/15/2009 2009 09/09/2009 09/08/2009 105 Nokia announced its first Linux phone couple of weeks ago. This presentation gives a brief look to its audio architecture and Pulseaudio’s role in it. I will give an idea what is unique about the approach we took and the reasoning behind it. I also go through the biggest challenges in the implementation and try to explain some of the not so elegant hacks we needed to make to create the product. 09/08/2009 2009 09/02/2009 05/04/2009 20 A special care must be taken by organizations to identify and correct software security vulnerabilities. Identifying and correcting software vulnerabilities earlier in the development cycle reduce patch management, incident response costs and mitigate possible software risks and potential exploits. In this talk we will be discussing the difference between software correctness/safety and software security, the difference between functional and risk-based security testing, white-box and black-box testing, the role of the Software Security Tester and the tools used in the process. We will be focusing on fuzz testing, discussing fuzzer implementations, its advantages and limitations and fuzzing initiatives like "The Month of Kernel Bugs" and "The Month of Browser Bugs". The objective is to define common guidelines for security testing on Linux, sharing our concern about software security and the importance of software security testing as part of the development process. 05/04/2009 2009 09/03/2009 06/15/2009 58 SELinux policy is currently treated as if it were another application. In most distributions, it is a single package that exists on its own as if it did not relate to the software to which it applies. Consequently, there is no way to ensure that policy matches installed applications. Further, any maintenance of policy must be performed manually via post install scripts, which is both tedious and error-prone. It is also very difficult to ensure that policy and the applications it confines are installed in the proper order, meaning that applications can be labeled improperly for a window of time. We propose solving this for package managers to treat policy as metadata rather than an application. This metadata can exist in the package of the application it applies to, or in system packages for more broad policy. This solution alleviates the pain of manually maintaining policy in scripts by giving the package manager enough information to manage policy automatically. By treating policy as metadata, it can be installed at the appropriate time in order to avoid ordering issues. As a side benefit, all policy module installations can be combined during a package manager transaction, reducing the performance hit taken when splitting policy into multiple packages. 06/15/2009 2009 09/05/2009 06/11/2009 39 Checkpoint/Restart is the ability to save the entire state of a running application and then resume the application either on the same system or a completely different system with a similar operating environment. A transparent C/R requires absolutely no changes to an application and does not even require a rebuild of the application. C/R provides several benefits to system administrators and users. Critical applications can be checkpointed at regular intervals and restarted from a recent checkpoint after a software/hardware upgrade or an application or system failure. The checkpointed application may even be restarted on second system with a similar operating environment during extended down times of the original system. C/R is especially useful to applications that have a long start-up times or incur significant performance penalty on startup due to parsing configuration information or populating a cache. Such applications can be checkpointed when running at optimal speed and can be resumed from the checkpoint when it becomes necessary to restart the application. C/R also enables significantly improved load-balancing and consolidation. When the load on a server goes up some applications on the server can be checkpointed and stopped on that server and the application can quickly be resumed on a new server. Similarly, when the load on several servers is low, the applications on those could be checkpointed and restarted on fewer servers, improving system utilization. For all its benefits, implementation of general purpose and transparent Checkpoint/Restart presents several complex and interesting challenges due to the vast and varied application state that needs to be saved and restored. The application state includes process memory, CPU registers, open file state, task relationships, signals state, SYSV IPC, sockets, network stack, device state etc. We are actively seeking to implement C/R in mainline, based on two existing out-of-tree implementations: Zap and OpenVZ. We would like to briefly go over our current implementation and present some major requirements, challenges and design decisions for broader review. But more importantly, we would like to understand and prioritize the devices, resources and state of HPC, X, Clusters and other applications that would need to be checkpointed and restarted. To that end, we would like to get input from administrators and users of such applications as well as from administrators and users of other C/R implementations. We would also like input from developers of the various subsystems in the Linux kernel on how C/R may impact their subsystems and how we could improve/stage the implementation. 06/11/2009 2009 09/14/2009 06/18/2009 77 For years kdb, kgdb and various other kernel debuggers have lived in different worlds, with different development communities. The time has come to try and merge these technologies so as to use a common low level API (the kernel debug core). This talk will explain the architectural differences between kgdb and kdb as well as to lay out a plan of how to combine the technologies to create a mostly architecture independent debugger. The talk will also explain the challenges that remain for adoption of the remaining pieces of kgdb that live outside the kernel.org tree today. The goal is to bring about awareness of the need for collaboration to continue to build an easy to use, robust kernel debugger, while not sacrificing kernel performance. In the spirit of building something at the conference the Jesse and Jason will collaborate to try and get a prototype working in order to demonstrate kernel mode setting and debugging some portion of the kernel. 06/18/2009 2009 09/03/2009 06/22/2009 87 A brief demonstration of X Access Control Extension (XACE) functionality using the SELinux extension for Xorg and a few supporting applications, including a compiz plugin for displaying window labels and input manager that supports the new XI2 extension and multiple mouse pointers. Afterwards, a discussion about the movement of memory management, command submission, and mode setting interfaces into the kernel, as they relate to fine-grained security controls. Is XACE relevant in environments such as Wayland? Would instrumentation of the kernel interfaces with LSM hooks be possible or appropriate? 06/22/2009 2009 09/05/2009 06/09/2009 30 Last years libv4l2 presentation ended with a slide future with the following bullet points (abbreviated): * Add emulated controls * Better handle rotation * Software image quality enhancements: - White balance – Normalize * Emulated controls persistency Actually quite a few of these have materialized in the recent 0.5.9x releases of libv4l. The talk will start with a short talk on what has been implemented, and more importantly how and the impact of this on existing applications and drivers. Last year Brandon Philips gave a talk about sharing video devices between multiple applications using a userspace video server. This is the next frontier for v4l userspace, the second part of this talk will describe several ideas how to handle this and the advantages and disadvantages of each, after which the intent is to further discuss this with the audience. 06/09/2009 2009 09/01/2009 06/15/2009 68 The Portland State Aerospace Society is developing a Linux based flight computer with sensor and operational nodes connected to the system through USB in isochronous mode. Most designs have margin to trade performance for reliability. Which choices in the Linux USB userspace interface will present which options? Is it better to write a kernelspace driver for known reliability or would it only be good for performance, or neither? There exists a finite amount of time in any design cycle to analyze these ideas for a given system. Once a designer makes a choice what monitoring and analysis options are available in the api? How can a developer ensure they are following userspace to kernel semantics, without intensive study of the kernel source code. Many people want to interface USB devices to host computers. Reducing the time and complexity involved in such integration can make it economical for manufacturers to write and provide drivers for their devices. Can the userspace api develop in a direction to support this? Discussing some of the challenges of the userspace interface to the Linux USB subsystem may provide some insight and ideas for improvement and encourage further use of Linux as a host system. 06/15/2009 2009 09/14/2009 06/14/2009 49 preempt-rt is a kernel community project to provide deterministic real-time support for the Linux kernel. Parts of preempt-rt have been merged into mainline already, but there are still key components of the patch to be merged. Give an overview about the state and the parts which need to be worked on for mainline acceptance along with general information about the key changes of preempt-rt and some insight about the challenges of providing real-time support for a general purpose OS. 06/14/2009 2009 09/01/2009 05/14/2009 21 Open source telephony stack for embedded/mobile devices and desktop/laptop computers. 05/14/2009 2009 08/18/2009 06/15/2009 59 ScaleMP vSMP Foundation is a form of aggregation virtualization. vSMP Foundation is a distributed virtual machine monitor (VMM) aggregating multiple similar x86-64 systems to make a single large shared memory system. The multiple systems are interconnected to each other with a commodity fast interconnect (currently Infiniband). The vSMP Foundation VMM takes care of aggregating all the constituent hardware of the aggregated system. This implies that the VMM also takes care of the memory/cache coherency among the constituent systems. Currently Linux is the only guest operating system that is supported by the vSMP Foundation. The vSMP Foundation VMM implements multiple inter-node coherency mechanisms. The resulting shared memory architecture is both "NUMA" and "COMA" in nature. The coherency mechanism chosen is transparent as far as the guest kernel is concerned (Applications can explicity choose a coherency mechanism though). Due to the software approach to coherency, and speeds of the existing commodity interconnects the NUMA factor of the aggregated system is fairly large. The COMA coherency domain results in a large internode cacheline size -- 4kB usually. Due to the above two reasons, cache misses and cacheline ping-pongs are a major issue. This talk will focus on solutions employed in the kernel and applications to overcome performance penalties due to the NUMA factors and large cacheline. The effects due to the large cacheline show up in different ways -- from the classical false sharing cases where traditional solutions based on padding could be employed to true sharing/lock contention cases where workarounds based on certain features in the Linux kernel and userspace libraries like hugetlb, libhugetlbfs, arena based allocations, third party malloc replacements, make more sense. This talk will detail all these workarounds and techniques used to date, some of the techniques we plan to use, and solicit suggestions on some unsolved issues. 06/15/2009 2009 09/01/2009 06/12/2009 40 Hypervisors each have their own set of command line tools, APIs, and interfaces – all of which are typically inoperable with other virtualization offerings. This can provide a difficult challenge for users with multiple hypervisor types within a given managed environment. One solution to this issue is to provide an abstraction layer that conforms to the Common Information Model (CIM). CIM is an open standard defined and published by the Distributed Management Task Force (DMTF) that describes how to control (and exchange information about) managed elements. Through the use of specification conformance, an administration client can interface with any CIM implementation using one set of APIs. The libvirt-cim project aims to provide such an abstraction layer for KVM, Xen, and Linux Containers. This talk will cover how libvirt-cim uses CIM, the DMTF specifications, and libvirt to manage guests and maintain hypervisor neutrality. The discussion will also include information on libcmpiutil – a library of utility functions, the goal of which is to reduce the amount of repetitive work typically done in most CMPI-style CIM providers. As KVM comes to the forefront, it has become increasingly important to provide ways to easily incorporate KVM into existing virtualization environments. The goal of this talk is to discuss ways in which CIM can be leveraged for that purpose. 06/12/2009 2009 08/18/2009 06/19/2009 78 Network devices have but a single name, and for systems with > 1 NIC, it's probably wrong. System administrators have long believed that 'eth0' was meaningful (i.e. it is the NIC that the system booted from, or is the first NIC on the motherboard of a system). However, for many reasons, this name is arbitrary, and may change from boot to boot. We need network device name aliases, just as we do for disk devices (/dev/disk/by-label/..., /dev/disk/by-uuid/...), so we can provide several meaningful names to network devices also. 06/19/2009 2009 08/18/2009 06/16/2009 69 Dracut is a generic, modular initramfs generation tool, that can be used across various distributions. Unlike existing initramfs's, this is an attempt at having as little as possible hard-coded into the initramfs as possible. The initramfs has (basically) one purpose in life -- getting the rootfs mounted so that we can transition to the real rootfs. This is all driven off of device availability. Therefore, instead of scripts hard-coded to do various things, we depend on udev to create device nodes for us and then when we have the rootfs's device node, we mount and carry on. This helps to keep the time required in the initramfs as little as possible so that things like a 5 second boot aren't made impossible as a result of the very existence of an initramfs. 06/16/2009 2009 09/14/2009 06/14/2009 50 Support for threaded interrupt handlers has been merged into mainline, but there is still work left to convert potential users and explore the full possibilities 06/14/2009 2009 09/14/2009 06/22/2009 88 This set of real-time benchmarks was designed with the hopes of becoming an accepted industry standard micro-benchmark suite to compare many of the common metrics of real-time performance across several platforms and several languages (C, C++ and Java). This allows for a comprehensive look at how these metrics compare across the platform axis and the languages axis. Most benchmarks, until now, have been throughput oriented, which does not help promote the strengths of real-time Linux. This benchmark suite introduces many more latency benchmarks which give a better view of how much more deterministic real-time Linux is compared to standard Linux. In addition to benchmarking these metrics, the benchmark suite can provide a great way to keep watch on kernel regressions and new bugs. By exercising the same kernel interfaces in a variety of ways with a variety of timings, we may be able to expose more kernel and glibc bugs. By adding the benchmark suite to an automated test server, such as test.kernel.org, we can keep an eye on the release-to-release performance of the real-time kernel. While the real-time tests in the Linux Test Project (LTP) do cover some of the same things, one of the major goals of this RT benchmark suite was to have a set of benchmarks that could run in a variety of languages, with a common test harness. 06/22/2009 2009 09/01/2009 05/20/2009 22 The current 2.6 kernels use a pdflush driven approach to writing out dirty data on. pdflush is a thread pool implementation that by default has anywhere from 2 to 8 threads running in the system. Each pdflush thread can be working a number of devices, however there can only be one pdflush active against a specific device at the time. This approach worked well and was a big step up from the 2.4 days where we had a single bdflush working all devices. There are, however, some problems with our current setup. pdflush has to work in non-blocking mode since it handles multiple devices, which can cause request starvation against a particular device since it cannot afford to wait for request allocation. There have also been reports on really fast devices out running pdflush, more than one thread would be needed to keep them running at full speed. This is not possible with the current design. I have implemented a new design for flushing dirty data, in which dirty inodes and flushing is tracked on a per-backing device basis. This reduces both locking scope and improves locality by keeping the flushing local to one (or a set) of thread(s). Keeping the dirty inode list local to the device instead of per-superblock also reduces the amount of scanning we have to do. No request starvation can happen with this design, as local threads are allowed to block on a single device. An experimental feature of this patch set is the ability to have multiple threads per backing device, with the file system directing the placement of inodes. Involvement from parties that suffer from pdflush being too slow for a single device will be required to finalize this. And finally, the new approach is a lot more flexible. Threads are created and exit lazily if no work has happened for a period of time. So it should be more flexible at both ends of the spectrum, having zero threads active on an writeback idle system and scaling to more threads than pdflush should it be needed. 05/20/2009 2009 09/14/2009 06/12/2009 41 Showing in detail the flow of actions from the kernel up into the end user applications and back. Major changes happened recently to the entire device handling stack. Abstractions of abstractions which didn't work out got removed from the system. HAL is no longer part of the game and replaced by the kernel, udev, DeviceKit and ConsoleKit. The basic idea stays the same, but the cake is cut into different pieces, and this is what will be explained here. 06/12/2009 2009 09/04/2009 06/19/2009 79 We'll cover some of the unique features of SELinux in Ubuntu including the update-selinux tools, policy configuration in /etc/selinux.d, and interaction with AppArmor. We'll also cover recent improvements such as the additional policy modules available in Jaunty and plans for future improvements. 06/19/2009 2009 09/03/2009 06/15/2009 60 Gallium is a open source 3D stack has become the standard driver infrastructure for writing new 3D drivers. And one can layer several rendering APIs on top of Gallium. These API interfaces are called state trackers, several exist: OpenGL, OpenVG, OpenGL ES and a video acceleration interface. So why not layer the X rendering on top of Gallium, use kernel side modesetting for bringing up display and write the last Xorg driver. Should we only accelerate parts of the EXA interface, try to strive for full EXA implementation or do our own X acceleration architecture and cover as much as possible of what is used by modern applications. 06/15/2009 2009 08/18/2009 06/09/2009 32 The FFADO project (www.ffado.org) provides drivers which allow an increasing number of professional firewire-based audio interfaces to be used under Linux. Over the past year a number of reliability issues have been addressed and the project is preparing for a version 2.0 release (due before LPC2009). Achieving the tight timing requirement of FFADO's streaming code remains an outstanding issue which we hope to overcome using a streaming helper module in the kernel (leaving the complex device discovery and control code in userspace). To leverage existing software it is planned to use an ALSA-compatible PCM device model to transfer audio data to and from userspace, although some questions on the detail remain. Work on coding this new module has just commenced. This talk will commence with a discussion of the more significant problems the project has encountered: both those which have been overcome and those which are still awaiting a final solution. Advantages of the recently merged threaded IRQ kernel infrastructure for FFADO will be highlighted. The rationale for a kernel-based solution to the timing issues will be given along with a description of the new streaming kernel module itself. Finally, the remaining interface details of the new kernel module will be raised with the intention of stimulating a discussion about the best way forward. 06/09/2009 2009 09/03/2009 06/16/2009 70 Currently, OpenGL, compositing window systems, and vertical refresh synchronized buffer swapping combine to make a giant mess. The current interfaces provided by GLX to synchronize buffer swaps don't work well with multi-monitor displays and don't really provide the functionality that applications want. Compositing window managers aren't able to get or provide the necessary information to ensure tear-free buffer swaps to all applications in a performant manner. At the intersection is disappointed users and frustrated application developers. This talk will present a brief overview of where we are and how we got here. The deficient software interfaces will then be enumerated, and possible enhancements to these interfaces will be presented. The talk will conclude by soliciting input from the audience. The problems highlighted by this talk have been growing over the past several years. It is clear that more input is needed to create a robust solution. 06/16/2009 2009 09/14/2009 09/14/2009 108 Modern CPUs have hardware dedicated to counting events associated with performance, special registers that allow pinpointing hotspots that can possibly be optimized. Recent developments in the Linux kernel explore these features, solving problems found in previous attempts, such as OProfile. The new tools developed to use it will be described and briefly demonstrated. 09/14/2009 2009 08/31/2009 06/14/2009 51 Some of the big audio infrastructure issues that were discussed at the audio track at LPC 2008 have been tackled since then. In this talk I want to give an overview what has been solved, what's still outstanding and which new problems have become visible. 06/14/2009 2009 08/18/2009 06/22/2009 89 The Proportional IO controller allows to distribute disk time to tasks/cgroups in proportion to their assigned weights. It leverages existing cgroup infrastructure for task grouping and supports specification of weights hierarchically. The IO controller uses hierarchical weighted fair queuing logic, which builds upon the Budget Fair Queuing (BFQ) scheduler proposed by Fabio Checconi and Paolo Valente. This logic is implemented at the common elevator layer that allows this approach to work with all four IO schedulers. Having this logic at the IO scheduler level and only one level of queuing makes sense as we can support existing IO priority class semantics. We plan to present/discuss goals and design overview of this io controller. A basic set of working patches are ready and we also plan to provide some test results and numbers. 06/22/2009 2009 08/18/2009 05/23/2009 23 Embedded Linux developers create lean customized systems from source code, which run on arbitrary hardware. But as these build systems grow to include more packages, they're faced with package management and repository maintenance issues. This can of worms results in numerous "accidental distributions" such as buildroot which spend the majority of their development effort maintaining package repositories. Modern Linux distributions have extensive and well-maintained package repositories, combined with deeply ingrained assumptions about their build environment. Modern Linux distributions are compiled under themselves; Fedora builds under Fedora, Debian builds under Debian, and even installing Gentoo (a distro designed around the idea of compiling everything from source) requires a specific prebuilt root filesystem tarball as a starting point. This makes it difficult to port these distributions to new hardware, customize them to remove "always enabled" features such as audio support, and swap out base packages for embedded versions such as busybox, uClibc, and dropbear. So if embedded build systems are hard to scale up, and full distributions are difficult to scale down, is there a way to mix and match them? Can we reproduce a modern distro entirely from source code under a _different_ build environment, one which may not even use the same processor? Can we customize the distribution's base environment to use different packages, or build individual packages from a distribution repository on top of an embedded base? We've made this work using a combination of the "Firmware Linux" and "Gentoo From Scratch" projects. The Firmware Linux stage is like an automated Linux From Scratch, using BusyBox and uClibc and targeted at a wider variety of hardware platforms. It creates a cross compiler toolchain for a target, uses it to build a native development root filesystem for that target, and packages the result to run under the emulator qemu. The Gentoo From Scratch stage then natively builds additional packages to extend this minimal build environment with the prerequisites for Gentoo's "portage", creating a usable "Gentoo Stage 1" environment from a non-gentoo starting point. This approach is designed as a series of orthogonal layers, each of which can be swapped out with a different implementation. We'll detail these layers and how to swap them out. We picked Gentoo for its existing focus on building from source, but will explain how to apply these same techniques to RPM or dpkg based systems. We'll also compare the ipkg and slackware approaches, cross compiling vs native compiling under emulation, and so on. The presenters are Rob Landley (author of Firmware Linux) and Mark Miller (author of Gentoo From Scratch), with a potential guest appearance by the maintainer of Gentoo Embedded. 05/23/2009 2009 08/31/2009 06/12/2009 42 We will first present challenges encountered when enabling hardware accelerators to reduce power-consumption or handle DRM-protected premium content. We show difficulties encountered with gstreamer auto-pluggin, sinks and dynamic re-routing between audio accessories. In the next section, we will focus on platform volume control and hierarchical mixing. On most devices, the final output is the result of both digital and analog mixing in a companion chip; we present examples and show the need for PulseAudio to control not only the native streams it processes, but also additional streams that are mixed in hardware, so that the user can control volumes all the way to the speaker. We will suggest several proposals based on ALSA controls or PulseAudio extensions. After we review several existing solutions, we will then show the need for standard communication channels between PulseAudio and audio apps to handle audio policy in a generic manner, and we will present the need to leave the choice of policy rules to the OEM or distribution maintainers. We believe such standardization would benefit not only the mobile community but improve the audio experience on all Linux devices. Last, we will discuss a generic plumbing issue when transmitting audio/video content to a distant renderer. In the case of HDMI v1.3 for example, the receiver can provide information on the latency of audio and video rendering; this lip-sync delay information is however not channeled from the ALSA driver back to PulseAudio or gstreamer. Likewise, the receiver capabilities in terms of supported channels, frequencies and formats are not forwarded to PulseAudio. The intent of this last section is to stimulate discussions in the Linux audio community on where lip-sync handling and receiver adaptation make the most sense. 06/12/2009 2009 08/18/2009 06/22/2009 80 The current X-Window cannot support remote video playback efficiently without video streaming technology. However, video streaming requires the receiver side to have specific video decoder for video content. There are few streaming based video-playback solutions in a typical X-Window use scenario where X client and server are on different systems. We are proposing a solution to distribute video playback task, and transmit common formatted data (RPC-like libVA message sequence) between two network ends. For the client, it only requires a GPU with a hardware video decoder core and corresponding driver. For the server, besides of the video content, it contains libVA and software video decoders used to invoke libVA. When a video file is playing back remotely, VA API sequence together with the source video data are transmitted from the server to the client over network. Then the client performs the hardware acceleration for video decoding/rendering. The initiative of the proposal is to solve the video playback efficiency issue in various current remote desktop solutions. 06/22/2009 2009 09/02/2009 06/15/2009 61 The "OSWALD":http://beaversource.oregonstate.edu/projects/cspfl/wiki was developed to encourage students to experiment and explore every aspect of computing. The OSWALD provides a flexible, yet powerful platform that can adapt to meet the needs of a large number of course topics and student interests. The OSWALD is also open and available to the greater Open Source community. The OSWALD is open from the ground up, from the hardware layer to the application layer. Every bit is available for students and enthusiasts to study and modify as needed. This talk will give you a quick overview of the architectural design of the OSWALD, and a discussion of the challenges we faced, and are still facing in getting a stable, complete, and usable software distribution for our Linux-based UMPC. 06/15/2009 2009 09/14/2009 09/14/2009 109 This talk is the infamous “Video API Deathmatch: VDPAU vs. VAAPI”, where “VDPAU” is NVIDIA’s Video Decode and Presentation API for Unix, and “VAAPI” is the Video Acceleration API led by Intel, and (not surprisingly) supported by recent Intel integrated graphics hardware, but also supported by recent S3 Graphics hardware. Stephen Warren will be putting on the gloves for VDPAU and Jonathan Bian will be defending VAAPI’s honor. Keith will then moderate the Q&A session, with questions taken from any surviving members of the audience. 09/14/2009 2009 09/02/2009 06/14/2009 52 The networking stack does not scale well with a single queue NIC on a multi-core system. The interrupt processing as well as the NAPI processing for a device, including protocol processing, are essentially single threaded on a CPU. In this talk we discuss a design that introduces parallelism in the networking receive path without the need for multi-queue NIC support. In essence this will emulate the capablities of hardware multi-queue NIC in that protocol processing of packets for different flows to be done in parallel. Applying this solution, we can show up to a 300% increase in the packets-per-second that can be handled with a single queue NIC. 06/14/2009 2009 09/14/2009 06/22/2009 90 System Management Interrupts (SMIs) are used to do a variety of system level tasks. These tasks extend the amount of functionality a system has outside of the OS. System vendors can perform everything from basic error reporting to advanced console or thermal management all without interaction from the OS. In Real-Time based systems these tasks can cause unwanted measurable latencies. Removing all non-fatal SMIs from a systems can reduce unwanted latencies and improve Real-Time system performance while providing enterprise level service. The OS must appropriately deal with non fatal ECC memory errors and implement any services that were provided by SMIs that are needed by the end user. Look at recent kernel and user space work as well as what is next. Address possible standardization and long term implications. 06/22/2009 2009 09/29/2009 06/10/2009 33 "Click Here to View the Slides":http://linuxplumbersconf.org/2009/slides/Dave-Hansen-oom-v3.pdf The Out of Memory (OOM) killer has consistently been a hotly debated topic in Linux. Having the wrong application killed as a result of an OOM condition can be very frustrating, and the root cause often remains elusive. Several knobs and controls have been exported but even these can be unsuitable for some. Many users dislike the default behavior and will either customize the code or replace it entirely. The OOM killer's behavior has also changed over time to the point where its appearance no longer indicates a true "out of memory" situation. There have been several patches to address these issues: the mem notify interface, per cgroup OOM controller, and various patches to change the OOM killer's log output. The goal of this session is to gather together the kernel developers interested in these features, other core VM developers, and the many users affected by OOM situations. Kernel developers know that, despite the hard work, some aspects of the OOM killer are still in need of improvement. This session will solicit user feedback to help the kernel developers properly gauge the past work and direct any efforts in the future. Kernel developers will come out of this session with an improved idea of how OOM situations affect users, how to best tailor the kernel's output for user consumption, and what features to work on next. Users will benefit from the session by learning how to better interpret the OOM situations to distinguish kernel from application bugs. They should also be much better prepared to use the kernel's new OOM-related features in their own environments. 06/10/2009 2009 08/18/2009 06/16/2009 71 Upstart is an event-driven replacement init daemon used by Ubuntu, Fedora, Maemo and Palm WebOS. This talk presents information about Upstart 1.0: what's new in that release and how far along the roadmap I am to it. 06/16/2009 2009 08/18/2009 05/25/2009 24 The "Embedded Systems track" title says: "Linux is embedded in everything, but where are the developers?" I'd like to try answering this question from point of view of small Linux developer in small embedded company. Indeed, there are quite a few companies that "do the right thing" and work hard to make their patches hit the mainline. However, the number of embedded developers involved in open source projects is small relatively to the number of devices that run Linux. I'll cover the process of embedded device development, constraints the embedded developers have and will try to analyze reasons for low number of contributions from the embedded world to open source. 05/25/2009 2009 09/03/2009 06/12/2009 43 Inadequate documentation was recently listed as one of problems related to using SELinux on the SELinux mailing list. Although many tools for SELinux have been created, there is still a perception that SELinux is too complicated to use. This talk will present a list of possible documentation improvements that can help change this perception. Note: Co-author Debora Velarde 06/12/2009 2009 09/02/2009 06/22/2009 81 Each namespace implements its own isolated network stack. Network packets comes to a network stack from network device. Five different device types that can be used as a packets sources for containers are demonstrated. Their properties (mostly performance and maintainability) and features are compared. In addition, one more device type is described -- the one that is currently only implemented in the OpenVZ containers. Its pros and cons, and ways it can be implemented in the mainline kernel are discussed. 06/22/2009 2009 09/05/2009 06/15/2009 62 USB 3.0 promises wirespeeds of 5Gbps, and supports new link power management and function power management. For Linux to take advantage of this new speed and PM features, both the USB and storage kernel subsystems and the USB userspace interface will need to be modified. This talk will provide a brief overview of USB 3.0 before diving into development issues. 06/15/2009 2009 08/31/2009 06/15/2009 53 Several in the networking community are skeptical on using interrupt threads for the network devices. I will argue that not only does it make the solution more simplex, but also increases network throughput. With the introduction of the threaded interrupt infrastructure into 2.6.30, the path has been paved to allow networking devices to take advantage of this. The threaded interrupt may then do all the work needed to hand off the packet to the thread code without all the complexities needed in locking while using the softirqs. I will present my ideas and even a working proof of concept, to convince those that still have doubts that the future of the network and Linux in general, is a kernel free from softirqs. 06/15/2009 2009 09/01/2009 06/22/2009 91 The Portland Oregon Regional Transportation Archive Listing (PORTAL) is the official transportation data archive for the Portland metropolitan region. PORTAL is being developed at Portland State University (PSU) by students and faculty in the Intelligent Transportation Systems Laboratory in cooperation with the Oregon Department of Transportation, Metro, the City of Portland, TriMet and other regional partners. PORTAL contains almost one terabyte of transportation-related data for the Portland metropolitan region. The data includes freeway speed and volume data as well as incident, weather, transit and freight-related data. In addition to the data archive, PORTAL has a web site that provides dynamic, user-customizable graphs and reports for analyzing transportation including plots of congestion, bottlenecks, speed maps and incident analysis. Presented here is a performance study showing how PostgreSQL and Linux handle the demands of all the PORTAL archive and web site. 06/22/2009 2009 09/03/2009 06/10/2009 34 This talk will cover configuration and use of 2.6.30's new Integrity Measurement Architecture (IMA). It will discuss IMA measurement policies, use and configuration of a hardware TPM for report signature and validation, and how to generate and use Trusted Computing Group standard formats and protocols for network admission and health-check. The talk will include demonstration of open source applications and libraries for these capabilities. 06/10/2009 2009 09/03/2009 06/17/2009 72 This talk surveys the recent developments in the Crypto API, and looks at ongoing work and future directions. Topics covered include hardware support, user-space APIs, and generalisation beyond cryptographic algorithms. 06/17/2009 2009 08/18/2009 05/27/2009 25 Over the last year, there have been a lot of improvements to the hardware side of e-paper. Among these have been improvements to display rate, support for color, and excitingly: flexible displays. It has been challenging for software to keep up with these capabilities. Some progress has been made: a driver for E-Ink's broadsheet controller (via 2.6.30) and kmalloc-ed fb support for defio (thanks to Magnus Damm). Early implementations of damage support (allows fbdev drivers to receive clip information from Xfbdev/etc), bitmap based dirty fb page tracking and other improvements have also been posted. Work is ongoing to support features such as video rate waveforms, and display slot management. This presentation will provide an overview of the changes to the hardware and software since last year, ideas for better support, the unsolved problems, and demonstrations of these devices. This presentation may be of interest to memory management, fbdev and userspace windowing/input developers. 05/27/2009 2009 08/18/2009 06/15/2009 63 With the pressure to decrease product development lifecycles, often with fewer resources, the challenges faced by embedded Linux developers have never been greater. Semiconductor vendors have become developers of the core Linux technology that enables their hardware and fully exploits its feature set yet Linux developers still lose valuable cycles enabling the hardware, customizing their systems, and integrating other software and tools. Designers find themselves locked into early software choices, unable to fully leverage the power of the open source community, and without the right tools to customize the software to their specific application requirements. This presentation addresses ways that developers can overcome these challenges, including using a Linux distribution that is tailored closely to their chosen hardware to help maintain the quality, control and consistency required to deliver commercial-ready devices to market faster. In addition to the control and trustworthiness of a commercial Linux OS, developers can reap the benefits of the open source community and deliver a customized platform to differentiate their end products. 06/15/2009 2009 09/02/2009 06/12/2009 44 Embedded system designers want to use asymmetric multiprocessing to supplement Linux with more specialized capabilities (e.g. tighter real-time bounds or better network throughput). In a nutshell, the idea is "co-operative partitioning": run multiple kernels, without isolation, on a multicore system. There are a number of issues in adapting Linux to ASMP environments, such as exactly how to get both kernels loaded, how to convince them to leave some hardware resources for each other, how to share hardware devices, and how to communicate. Especially this last point is very similar to issues found in traditional coprocessor (e.g. CompactPCI) or FPGA systems. Using existing solutions, such as Open Firmware-inspired device trees and virtio drivers, can save developer time and make Linux better faster for these applications. 06/12/2009 2009 08/18/2009 06/22/2009 82 Open Source distributed hacking is awesome, but you knew that already. Pair programming is awesome too, and you might not have known that yet. But Open Source hackers don't tend to do much pair programming, except perhaps at the occasional conference hack session. We want to show you some tools and techniques for pair programming in a distributed manner, and some case studies where we solved hard problems this way. 06/22/2009 2009 08/18/2009 06/15/2009 54 Currently, one severe limitation of Xserver is that it cannot draw anything accelerated past a hardware-dependent limit, known as the scanout limit. As a consequence, no accelerated 2D or 3D can happen on monitors outside the scanout limit, and for users with multiple monitors, this is a constant source of disappointment and frustration. Shatter resolves this problem by removing the old Virtual desktop setup, which allocated the framebuffer statically at startup, and instead, it leverages kernel memory management to allocate scanout framebuffers dynamically, as needed. This presentation will explain how Shatter works, which problems it solves, and why it is, in general, awesome. 06/15/2009 2009 09/15/2009 06/22/2009 92 Last year Brandon presented on the need for a video4linux server and some details on how it might be done. This session will build on that initial discussion and will include details and research done by Hans and Brandon about specific approaches over the coming months before the conference. 06/22/2009 2009 08/18/2009 06/10/2009 35 Every few years, even the best hardware hits the end of its useful life and users need to migrate their data from old hardware to new hardware. Doing this for small devices with a few gigabytes of user data is pretty easy, but most of us have increasingly large personal storage both at home and at work. This talk will focus on some of the challenges in migrating data from old, potentially failing hardware to new hardware: dealing quickly with IO errors, how to optimize the list of files to move and suggestions about how to handle failures during migration. 06/10/2009 2009 08/18/2009 06/17/2009 73 KVM runs on most major platforms available these days, including x86(_64), IA64, S390 and embedded PPC. Up to now the PowerPC support was limited to embedded processors which I decided to change. This talk will show you how I implemented KVM support for PowerPC, which issues I ran into and how powerful everything is now. 06/17/2009 2009 09/03/2009 06/02/2009 26 Fedora 11 introduced the concept of the General purpose sandbox. The idea is you can run processes within the sandbox that work on untrusted data or even the tools is untrusted and guarantee that the tools has access to only Stdin and STDOUT and very little of the system. We also plan to demonstrate the SELinux Xwindows Sabdbox at this time. 06/02/2009 2009 09/02/2009 06/15/2009 64 This talk will describe the status of the cfg80211 API and what is being done to finalize it development and spread its adoption. It will discuss the features available both inside the kernel and to userland application as part of that API. Finally, it will talk about adapting drivers to the cfg80211 API and discuss what needs to happen to put a stake in the heart of the wireless extensions API for good. 06/15/2009 2009 08/18/2009 06/13/2009 45 This talk is about presenting the current git bisect features. Then discussing how some people are using it and how they can help application and kernel users and developers. And eventually talking about future git bisect features. 06/13/2009 2009 08/18/2009 06/22/2009 83 Existing projects like "pristine-tar":http://kitenet.net/~joey/code/pristine-tar/ focus on finding the right options to the compression code to reproduce the file from the uncompressed data ("gzip -9 --rsyncable"), treating the file formats as magic black boxes. Our in-depth analysis of archive formats lets us record just enough information to reproduce any archive regardless of the tool used to produce it. 06/22/2009 2009 08/18/2009 04/16/2009 17 The Linux VFS contains a number of complex data structures to represent and manage filesystem and namespace details. This includes "dcache", which is a cache of the directory entry layout of mounted filesystems, "inode cache" to cache filesystems' inode metadata, among others. These data structures tend to be protected with global locks which do not scale well as CPU core count increases. I am working on implementing fine grained locking for some of the important cases. To date I have posted patches to remove the global dcache lock for initial review. These already provide about 50% performance gain on the dbench workload on an 8 core system. I would like to give a presentation on my progress on this project. This presentation should describe my designs and give some results, but also implementation problems that I am encountering, with a mind to getting vfs and filesystem developers interested and hopefully helping with ideas. 04/16/2009 2009 08/18/2009 06/11/2009 36 Using the IEEE 802.1Qaz Priority Grouping and Data Center Bridging concepts to group multiple traffic flows, this talk will demonstrate how different types of traffic, such as storage and LAN traffic, can efficiently coexist on the same physical connection. With the support of multi-core systems and MSI-X, these different traffic flows can achieve latency and throughput comparable to the same traffic types' specialized adapters. 06/11/2009 2009 09/01/2009 06/17/2009 74 Virtualization is usually only one level deep. So in a normal virtual environment you can not run a hypervisor again. While that is reasonable for most use cases, it can come in handy to have virtualization support within your virtual machine. Especially when you develop a virtualization product. So I implemented nested SVM. Basically, that exposes virtualization capabilities within the virtual machine and allows you to run any hypervisor within your VM that would work on a real machine, as long as you're running on AMD hardware. This talk will give you an overview on how this is achieved (technically), what limitations there are and how fast we can get. 06/17/2009 2009 08/18/2009 06/15/2009 55 In 2004, a patch to the Linux kernel introduced meaningful scheduler statistics for the first time. The decisions of the scheduler can have a profound impact on overall system performance, and this patch provided, for the first time, a means to more closely examine those decisions under a variety of workloads. Although the kernel has continued to evolve, these statistics have remained fairly static until the publication of the real-time Linux work in late 2006 by Ingo Molnar. That work has led to new mechanisms to measure process latency and measurement of some new aspects of the scheduler that had not previously been measured. Additionally, the scheduler itself has undergone dramatic changes in 2007 and 2008. Five years have passed since the original schedstats patch was accepted. Having two sets of statistics on the same subsystem can be both confusing and wasteful. This talk examines the existing mechanisms for measuring scheduler performance and discusses whether any of these statistics should be eliminated, combined, or enhanced. 06/15/2009 2009 09/05/2009 06/04/2009 27 Power management is still often thought of as a set of static policies that will be enacted whenever the system becomes idle. However, much of the power savings in a modern system are adaptive and entirely transparent to the user. The aim now is to take this even further. Even greater power savings can be achieved if we can disable certain aspects of hardware functionality. But how can we infer when it's safe to do so? How can we identify userspace's needs and make sure that they're satisfied? How aggressive can we be at entering these lower power states? This presentation will discuss some of the existing interfaces (such as pm_qos) that exist for userspace to inform the kernel of requirements. It will also discuss what other sources of information already exist and can be tied into power management, along with cases where we lack any infrastructure to communicate desires and hence sacrifice one of either functionality or power. The aim is to identify our current shortcomings and propose ways to allow userspace to communicate its desires to the kernel. 06/04/2009 2009 08/18/2009 06/15/2009 65 Routing 64 byte packets bidirectionally is the standard test for many LAN and platform customers of Intel. Routing at line rate is the holy grail, and while CPU speed and memory bandwidth is increasing dramatically, actually using that bandwidth with an Ethernet I/O device is difficult. This paper will explain some of the tuning and results we have achieved with the latest generation of 10 Gigabit ethernet hardware combined with the latest processors/chipsets. 06/15/2009 2009 08/18/2009 06/13/2009 46 RCU is well-known at the kernel-level for providing a way to synchronize shared data structures in read-often, update-rarely scenarios. The development of a RCU library at the userspace application level has been mainly driven by the need for efficient synchronization of userspace tracing control data structures. IBM kindly agreed to allow distribution of RCU-related code in a LGPL library, which makes it available for everyone to use. This can have large impact on the design of highly scalable applications performing caching of frequent requests, like domain name servers, proxy and web servers. This presentation will discuss about the class of applications which could benefit from using the userspace RCU library. The userspace RCU library is available under the LGPL license at http://www.lttng.org/urcu . 06/13/2009 2009 08/18/2009 06/22/2009 84 While the boot process of a Linux system has received a lot of attention recently, certain aspects are still poorly understood. We aim to demystify two of these. initramfs is usually ignored unless it's broken. We illuminate this often-misunderstood system, including its history, rationale, capabilities, loading process, and the kernel's built-in userspace. ELF(Executable and Linking Format) has many capabilities, of which Linux binaries use only a subset. We explore the format in detail, including the loading process, ld.so and interpreters, and rpath and its implications for Linux distributions. 06/22/2009 2009 08/18/2009 04/18/2009 18 Since the 2008 Plumbers Conference a lot of work was put into a new V4L2 core framework. Much of that framework was designed during that conference and the initial version was merged in the 2.6.30 kernel. This talk describes what was done in the past year and what is planned for the future. This part of the talk welcomes contributions from the audience since this will help me decide on which part to focus first. 04/18/2009 2009 09/04/2009 06/11/2009 37 By Data de-duplication,only one unique instance of the data is actually retained on storage media, such as disk or tape or a virtual machine image. This not only reduces large storage needs but also and reduce the corresponding cost of backup, disaster recovery and power consumption. It becomes a hot topic with increasing need for large storage. Adding support of data de-duplication today makes Linux much stronger in enterprise environment. Whether support data de-duplication on the air within filesystem or perform delayed user-space de-duplication have different challenges. This talk will discuss about the challenges of both methods, options, describe several ideas discussed in the btrfs community. This talk encourages inputs and ideas from audience about future plans about data deduplication for linux. 06/11/2009 2009 08/18/2009 06/17/2009 75 A talk to allow the exchange of experiences with multicasting. Tips and tricks of how to use multicasting with Linux. What software and hardware is available for multicasting and what are the operating boundaries of either. 06/17/2009 2009 09/03/2009 06/15/2009 56 The SELinux experience has greatly improved since SELinux's first appearance in distributions. Many people now run SELinux without even knowing, or even caring, that it exists. It still, however, has a reputation for being extremely complicated and heavy-weight, and very few people ever attempt to actually customize the SELinux policy to meet their specific security goals. While part of the perception of complexity is real and a consequence of the complexity of the typical modern system which SELinux is controlling, the policy infrastructure, which has grown organically over time, contributes to the problem by being brittle and inflexible, hampering efforts to add new features and hindering experimentation in such things as higher-level policy languages. If the SELinux experience is going to continue to improve, the policy infrastructure must be improved. A new architecture for the policy infrastructure has been designed and is being implemented. This architecture will support higher-level languages by providing a better intermediate language that provides more flexible and useful language abstractions to build higher-level language constructs. It will better support the use of additional tools (such as policy goal verifiers) during a policy build. It will allow for the separation of the distribution's policy from the local customizations of that policy. In general, this new architecture will eliminate the brittleness and inflexibility that is currently hindering improvements to SELinux. 06/15/2009 2009 08/18/2009 06/22/2009 94 Do we currently have sufficient tools to persuade management or business owners to invest in appropriate lifecycle management, or in some cases a major re-architecture of their core infrastructure? I personally think not. So what needs to be done about it? First we need to capture sufficient information about our environment. Often there will be inadequate documentation and we must resort to * Custom Scripts * Open Source tools * Visual inspection We can then start attributing a cost to maintaining * Legacy Operating Systems * Old Hardware * Unsupported middleware Should the community be providing better tools to assist this process and quantify the costs? Perhaps the tools can also be used to assist the transition of legacy Unix or Windows systems to Linux, rather than the current ever increasing number of virtualised legacy Windows environments. The talk will be guided by Steven's considerable experience in large and small infrastructure environments where he has seldom been lucky enough to approach green fields project. Outcomes should include guidance on appropriate tools and a framework for ongoing lifecycle management. 06/22/2009