DOCSLIB.ORG

Writing AIX Device Driver Programs

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

AIX Version 7.2 Writing AIX Device Driver Programs IBM Note Before using this information and the product it supports, read the information in “Notices” on page 3 . This edition applies to AIX Version 7.2 and to all subsequent releases and modifications until otherwise indicated in new editions. © Copyright International Business Machines Corporation 2019. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. About this document This document provides detailed information about AIX device drivers. You can use this document to access configuration settings of sample device drivers and to access the instructions to run sample device drivers. Highlighting The following highlighting conventions are used in this document: Bold Identifies commands, subroutines, keywords, files, structures, directories, and other items whose names are predefined by the system. Bold highlighting also identifies graphical objects, such as buttons, labels, and icons that the you select. Italics Identifies parameters for actual names or values that you supply. Identifies examples of specific data values, examples of text similar to what you Monospace might see displayed, examples of portions of program code similar to what you might write as a programmer, messages from the system, or text that you must type. Case sensitivity in AIX Everything in the AIX® operating system is case sensitive, which means that it distinguishes between uppercase and lowercase letters. For example, you can use the ls command to list files. If you type LS, the system responds that the command is not found. Likewise, FILEA, FiLea, and filea are three distinct file names, even if they reside in the same directory. To avoid causing undesirable actions to be performed, always ensure that you use the correct case. ISO 9000 ISO 9000 registered quality systems were used in the development and manufacturing of this product. Support for the single UNIX specification The AIX operating system is designed to support The Open Group's Single UNIX Specification Version 3 (UNIX 03) for portability of operating systems based on the UNIX operating system. Many new interfaces, and some current ones, have been added or enhanced to meet this specification. To determine the correct way to develop a UNIX 03 portable application, see The Open Group's UNIX 03 specification on The UNIX System website (http://www.unix.org). © Copyright IBM Corp. 2019 v Chapter 1. Device Driver Overview Many computer programs are dedicated to working with attached devices in some way. For example, there are programs to send control characters to a printer, programs to receive characters from a terminal, and programs to read data from a tape. In a broad sense, each of these programs is a device driver because the program is dedicated to handling input from or output to a device. Such programs are usually regarded as being part of, or an extension of, the computer’s operating system. Any operating system that supports multitasking (such as AIX) needs some way to prevent one program from writing to, or changing the state of, some device that is already being accessed by another program. So, a multitasking operating system relies on the computer's processors to distinguish between privileged and non-privileged execution of instructions. Therefore, one must distinguish between programs that execute in privileged mode (kernel mode) and those that execute in user mode. The AIX kernel consists of all software that executes in kernel mode. Even though AIX programs that execute in user mode can drive devices, such as a network adapter or some device attached to a USB port, they can only do so by invoking software that is part of the kernel. Because kernel device drivers are considerably more complex than drivers that execute in user mode, from here on, the term device driver will only refer to software that handles a device while executing in kernel mode. Device drivers are more complex than user software for several reasons: • Device drivers output data to a device or demand data from a device. This means that the driver may have to read or write to registers on a card attached to an I/O bus, or the driver may have to set up the means for the data to be transferred in some other way. A device driver is intimately interconnected with processor memory design, how the processor performs I/O, and with the architecture of the I/O bus attached to the system. So, device drivers are not portable; migrating the driver routines from one system to another often requires the routines to be rewritten. • Device drivers may have to process interrupts generated by a card attached to the system I/O bus. When a terminal sends a character to the computer, or a disk drive has completed writing a block of data, the card serving as an adapter between the device and the I/O bus on the computer generates an interrupt. The software routines, within a device driver, that process interrupts (called interrupt handlers) take some sort of action like buffering incoming data, or signaling a process. Because such interrupts occur asynchronously, meaning that they occur without regard to what instructions the computer’s processors are executing, the interrupt may occur while a processor on the computer is in the middle of handling another interrupt. Therefore, interrupt handlers must be reentrant; in other words, they must be able to access shared resources (such as non-private data) and exclude concurrent access by any software including another instance of itself. Device driver routines that (asynchronously) execute in the context of handling an interrupt are said to be, on the interrupt side, and are occasionally referred to as the device handler, but this is not the same thing as a network device handler. Device driver routines that (synchronously) execute in the context of a calling process are said to be on the call side. For more information on concurren t access o f shared data, see Chapter 5, “Synchronization and Serialization.” Device Driver Overview 1-1 • Device drivers may have to execute in real time. Device drivers may have to respond to an interrupt, or perform some other function within a certain fixed period of time. • A device driver is a collection of routines. There is no main routine. The rou tines are usu ally wri tten in C an d co mpiled to pr oduce on e o r two Ex tende d Obje ct File Forma t (XCOFF o r XCOFF 64) object files. Begin ning with AIX V ersio n 6, a ll device driv ers are 64-b it only (XCOFF64): ther e no lo ng er support for 3 2-bit dev ice driv ers. The obj ect file s are link ed to en a ble the ker n el loader to r es olve ker nel sym bols. As a resu lt of linki ng , the loa der section is filled o ut wit h a list of sy m bo ls to imp ort from th e kernel. The sy mbo ls are in t he fi le /lib /ke rnex.exp. The linking also es tabli shes the dri ver’ s configuratio n routine as t he defa ult entr y point for be ginni ng execution. A simple ex a mple is shown in “Sa m ple De vice Driver” on pag e 1-15 . Aspects of the Kernel that Affect Device Drivers There are a number of attributes of the AIX kernel that affect device drivers: • Kernel routines can only call kernel services. Kernel routines cannot call routines meant to execute in user mode. So, device driver routines are not linked with the C library libc.a, nor can they invoke system calls. The re are some kernel DMA and timer routines in libsys.a, and there are some C library calls written to execute in kernel mode in the library libcsys.a. For more information on the m, please refer to U nders tanding K erne l B inding. • Kernel code and data that is not pinned (explicitly or implicitly) is paged into system RAM from a paging logical volume on disk. So, one must distinguish between device driver routines that are to be collectively pinned, called the bottom half, and those that are to be paged, called the top half. Because device driver routines on the interrupt side must be pinned, the phrases in the bottom half and on the interrupt sideare sometimes used as if they are synonyms, but they really are not synonyms. Due to real-time concerns, sometimes routines on the call side are placed in the bottom half. • Kernel routines are difficult to debug. There is a kernel debugger, kdb, but it is not as easy to use as is dbx. References to improper addresses may cause data corruption (because the kernel is privileged) or a system crash. It is possible to trace the execution of a device driver with printf; but printf only prints to a native serial/console port, when the kernel debugger is enabled . Also it may affect a device driver ’s timing. See Debug Facilities for more details on debugging • Execution of kernel routines, in the context of a process, can be preempted by the scheduler in favor of a process with greater priority. This means that device driver routines cannot depend on disabling interrupts as being sufficient to avert concurrent access to shared resources. It also means that drivers (not just interrupt handlers) must be reentrant. • The AIX kernel is dynamically extendible. Object files acceptable to the kernel loader, are bound into the AIX kernel while the computer is still operating; there is no need to restart the system.
Recommended publications
  • A Programmable Microkernel for Real-Time Systems∗

    A Programmable Microkernel for Real-Time Systems∗

    A Programmable Microkernel for Real-Time Systems∗ Christoph M. Kirsch Marco A.A. Sanvido Thomas A. Henzinger University of Salzburg VMWare Inc. EPFL and UC Berkeley [email protected] tah@epfl.ch ABSTRACT Categories and Subject Descriptors We present a new software system architecture for the im- D.4.7 [Operating Systems]: Organization and Design— plementation of hard real-time applications. The core of the Real-time systems and embedded systems system is a microkernel whose reactivity (interrupt handling as in synchronous reactive programs) and proactivity (task General Terms scheduling as in traditional RTOSs) are fully programma- Languages ble. The microkernel, which we implemented on a Strong- ARM processor, consists of two interacting domain-specific Keywords virtual machines, a reactive E (Embedded) machine and a proactive S (Scheduling) machine. The microkernel code (or Real Time, Operating System, Virtual Machine microcode) that runs on the microkernel is partitioned into E and S code. E code manages the interaction of the system 1. INTRODUCTION with the physical environment: the execution of E code is In [9], we advocated the E (Embedded) machine as a triggered by environment interrupts, which signal external portable target for compiling hard real-time code, and in- events such as the arrival of a message or sensor value, and it troduced, in [11], the S (Scheduling) machine as a universal releases application tasks to the S machine. S code manages target for generating schedules according to arbitrary and the interaction of the system with the processor: the exe- possibly non-trivial strategies such as nonpreemptive and cution of S code is triggered by hardware interrupts, which multiprocessor scheduling.
  • The Linux Kernel Module Programming Guide

    The Linux Kernel Module Programming Guide

    The Linux Kernel Module Programming Guide Peter Jay Salzman Michael Burian Ori Pomerantz Copyright © 2001 Peter Jay Salzman 2007−05−18 ver 2.6.4 The Linux Kernel Module Programming Guide is a free book; you may reproduce and/or modify it under the terms of the Open Software License, version 1.1. You can obtain a copy of this license at http://opensource.org/licenses/osl.php. This book is distributed in the hope it will be useful, but without any warranty, without even the implied warranty of merchantability or fitness for a particular purpose. The author encourages wide distribution of this book for personal or commercial use, provided the above copyright notice remains intact and the method adheres to the provisions of the Open Software License. In summary, you may copy and distribute this book free of charge or for a profit. No explicit permission is required from the author for reproduction of this book in any medium, physical or electronic. Derivative works and translations of this document must be placed under the Open Software License, and the original copyright notice must remain intact. If you have contributed new material to this book, you must make the material and source code available for your revisions. Please make revisions and updates available directly to the document maintainer, Peter Jay Salzman <[email protected]>. This will allow for the merging of updates and provide consistent revisions to the Linux community. If you publish or distribute this book commercially, donations, royalties, and/or printed copies are greatly appreciated by the author and the Linux Documentation Project (LDP).
  • Interrupt Handling in Linux

    Interrupt Handling in Linux

    Department Informatik Technical Reports / ISSN 2191-5008 Valentin Rothberg Interrupt Handling in Linux Technical Report CS-2015-07 November 2015 Please cite as: Valentin Rothberg, “Interrupt Handling in Linux,” Friedrich-Alexander-Universitat¨ Erlangen-Nurnberg,¨ Dept. of Computer Science, Technical Reports, CS-2015-07, November 2015. Friedrich-Alexander-Universitat¨ Erlangen-Nurnberg¨ Department Informatik Martensstr. 3 · 91058 Erlangen · Germany www.cs.fau.de Interrupt Handling in Linux Valentin Rothberg Distributed Systems and Operating Systems Dept. of Computer Science, University of Erlangen, Germany [email protected] November 8, 2015 An interrupt is an event that alters the sequence of instructions executed by a processor and requires immediate attention. When the processor receives an interrupt signal, it may temporarily switch control to an inter- rupt service routine (ISR) and the suspended process (i.e., the previously running program) will be resumed as soon as the interrupt is being served. The generic term interrupt is oftentimes used synonymously for two terms, interrupts and exceptions [2]. An exception is a synchronous event that occurs when the processor detects an error condition while executing an instruction. Such an error condition may be a devision by zero, a page fault, a protection violation, etc. An interrupt, on the other hand, is an asynchronous event that occurs at random times during execution of a pro- gram in response to a signal from hardware. A proper and timely handling of interrupts is critical to the performance, but also to the security of a computer system. In general, interrupts can be emitted by hardware as well as by software. Software interrupts (e.g., via the INT n instruction of the x86 instruction set architecture (ISA) [5]) are means to change the execution context of a program to a more privileged interrupt context in order to enter the kernel and, in contrast to hardware interrupts, occur synchronously to the currently running program.
  • SYSTEM V RELEASE 4 Migration Guide

    SYSTEM V RELEASE 4 Migration Guide

    - ATlaT UN/~ SYSTEM V RELEASE 4 Migration Guide UNIX Software Operation Copyright 1990,1989,1988,1987,1986,1985,1984,1983 AT&T All Rights Reserved Printed In USA Published by Prentice-Hall, Inc. A Division of Simon & Schuster Englewood Cliffs, New Jersey 07632 No part of this publication may be reproduced or transmitted in any form or by any means-graphic, electronic, electrical, mechanical, or chemical, including photocopying, recording in any medium, tap­ ing, by any computer or information storage and retrieval systems, etc., without prior permissions in writing from AT&T. IMPORTANT NOTE TO USERS While every effort has been made to ensure the accuracy of all information in this document, AT&T assumes no liability to any party for any loss or damage caused by errors or omissions or by state­ ments of any kind in this document, its updates, supplements, or special editions, whether such er­ rors are omissions or statements resulting from negligence, accident, or any other cause. AT&T furth­ er assumes no liability arising out of the application or use of any product or system described herein; nor any liability for incidental or consequential damages arising from the use of this docu­ ment. AT&T disclaims all warranties regarding the information contained herein, whether expressed, implied or statutory, including implied warranties of merchantability or fitness for a particular purpose. AT&T makes no representation that the interconnection of products in the manner described herein will not infringe on existing or future patent rights, nor do the descriptions contained herein imply the granting or license to make, use or sell equipment constructed in accordance with this description.
  • Introduction to Linux Kernel Driver Programming

    Introduction to Linux Kernel Driver Programming

    IntroductionIntroduction toto LinuxLinux kernelkernel driverdriver programmingprogramming Introduction to Linux kernel driver programming The Linux kernel device model Authors and license ● Authors – Michael Opdenacker ([email protected]) Founder of Bootlin, kernel and embedded Linux engineering company https://bootlin.com/company/staff/michael-opdenacker ● License – Creative Commons Attribution – Share Alike 4.0 https://creativecommons.org/licenses/by-sa/4.0/ – Document sources: https://github.com/e-ale/Slides Need for a device model ● For the same device, need to use the same device driver on multiple CPU architectures (x86, ARM…), even though the hardware controllers are different. ● Need for a single driver to support multiple devices of the same kind. ● This requires a clean organization of the code, with the device drivers separated from the controller drivers, the hardware description separated from the drivers themselves, etc. Driver: between bus infrastructure and framework In Linux, a driver is always interfacing with: ● a framework that allows the driver to expose the hardware features in a generic way. ● a bus infrastructure, part of the device model, to detect/communicate with the hardware. Let’s focus on the bus infrastructure for now Device model data structures The device model is organized around three main data structures: ● The struct bus_type structure, which represent one type of bus (USB, PCI, I2C, etc.) ● The struct device_driver structure, which represents one driver capable of handling certain devices on a certain bus. ● The struct device structure, which represents one device connected to a bus The kernel uses inheritance to create more specialized versions of struct device_driver and struct device for each bus subsystem.
  • Additional Functions in HW-RTOS Offering the Low Interrupt Latency

    Additional Functions in HW-RTOS Offering the Low Interrupt Latency

    HW-RTOS Real Time OS in Hardware Additional Functions in HW-RTOS Offering the Low Interrupt Latency In this white paper, we introduce two HW-RTOS functions that offer the lowest interrupt latency available and help create a more software-friendly environment. One of these is ISR implemented in hardware, which improves responsiveness when activating a task from an interrupt and eliminates the need for developing a handler in software. The other is a function allowing the use of non-OS managed interrupt handlers in a multitasking environment. This makes it easier to migrate from a non-RTOS environment to a multitasking one. R70WP0003EJ0100 September, 2018 2 / 8 Multitasking Environment with Lowest Interrupt Latency Offered by HW-RTOS 1. Executive Summary In this white paper, we introduce two functions special to HW-RTOS that improve interrupt performance. The first is the HW ISR function. Renesas stylized the ISR (Interrupt Service Routine) process and implemented it in hardware to create their HW ISR. With this function, the task corresponding to the interrupt signal can be activated directly and in real time. And, since the ISR is implemented in the hardware, application software engineers are relieved of the burden of developing a handler. The second is called Direct Interrupt Service. This function is equivalent to allowing a non-OS managed interrupt handler to invoke an API. This function %" "$# $""%!$ $ $""%!$!" enables synchronization and communication "$ "$ between the non-OS managed interrupt handler and $($ $($ '$ '$ tasks, a benefit not available in conventional $ $ software. In other words, it allows the use of non-OS # $ % " "$) ) managed interrupt handlers in a multitasking $($ '$ environment.
  • The Linux Device File-System

    The Linux Device File-System

    The Linux Device File-System Richard Gooch EMC Corporation [email protected] Abstract 1 Introduction All Unix systems provide access to hardware via de- vice drivers. These drivers need to provide entry points for user-space applications and system tools to access the hardware. Following the \everything is a file” philosophy of Unix, these entry points are ex- posed in the file name-space, and are called \device The Device File-System (devfs) provides a power- special files” or \device nodes". ful new device management mechanism for Linux. Unlike other existing and proposed device manage- This paper discusses how these device nodes are cre- ment schemes, it is powerful, flexible, scalable and ated and managed in conventional Unix systems and efficient. the limitations this scheme imposes. An alternative mechanism is then presented. It is an alternative to conventional disc-based char- acter and block special devices. Kernel device drivers can register devices by name rather than de- vice numbers, and these device entries will appear in the file-system automatically. 1.1 Device numbers Devfs provides an immediate benefit to system ad- ministrators, as it implements a device naming scheme which is more convenient for large systems Conventional Unix systems have the concept of a (providing a topology-based name-space) and small \device number". Each instance of a driver and systems (via a device-class based name-space) alike. hardware component is assigned a unique device number. Within the kernel, this device number is Device driver authors can benefit from devfs by used to refer to the hardware and driver instance.
  • Topic 10: Device Driver

    Topic 10: Device Driver

    Topic 10: Device Driver Tongping Liu University of Massachusetts Amherst 1 Administration • Today it is the deadline of Project3 • Homework5 is posted, due on 05/03 • Bonus points: ECE570 – 3 points, ECE670-5 points – Design exam questions – Process&threads, scheduling, synchronization, IPC, memory management, device driver/virtualization – Due: 05/01 • Survey project (ECE570/ECE670): 05/12 University of Massachusetts Amherst 2 Objectives • Understanding concepts of device driver, e.g., device number, device file • Understand the difference of kernel modules and device drivers • Learn how to implement a simple kernel module • Learn how to implement a simple device driver University of Massachusetts Amherst 3 Outline • Basic concepts • Kernel module • Writing device driver University of Massachusetts Amherst 4 Device Driver • A special kind of computer program that operates or controls a particular type of device that is attached to a computer University of Massachusetts Amherst 5 Device Driver • A special kind of computer program that operates or controls a particular type of device that is attached to a computer – Needs to execute privileged instructions – Must be integrated into the OS kernel, with a specific format – Interfaces both to kernel and to hardware University of Massachusetts Amherst 6 Whole System Stack Note: This picture is excerpted from Write a Linux Hardware Device Driver, Andrew O’Shauqhnessy, Unix world University of Massachusetts Amherst 7 Another View from OS University of Massachusetts Amherst 8 Type of Devices • Character device – Read or write one byte at a time as a stream of sequential data – Examples: serial ports, parallel ports, sound cards, keyboard • Block device – Randomly access fixed-sized chunks of data (block) – Examples: hard disks, USB cameras University of Massachusetts Amherst 9 Linux Device Driver • Manage data flow between user programs and device • Typically a self-contained kernel module – Add and remove dynamically • Device is a special file in /dev that user can access, e.g.
  • Analyst® Device Driver 1.3 Release Notes 2 / 16 RUO-IDV-03-1997-E Contents

    Analyst® Device Driver 1.3 Release Notes 2 / 16 RUO-IDV-03-1997-E Contents

    Analyst® Device Driver 1.3 Release Notes RUO-IDV-03-1997-E May 2018 This document is provided to customers who have purchased SCIEX equipment to use in the operation of such SCIEX equipment. This document is copyright protected and any reproduction of this document or any part of this document is strictly prohibited, except as SCIEX may authorize in writing. Software that may be described in this document is furnished under a license agreement. It is against the law to copy, modify, or distribute the software on any medium, except as specifically allowed in the license agreement. Furthermore, the license agreement may prohibit the software from being disassembled, reverse engineered, or decompiled for any purpose. Warranties are as stated therein. Portions of this document may make reference to other manufacturers and/or their products, which may contain parts whose names are registered as trademarks and/or function as trademarks of their respective owners. Any such use is intended only to designate those manufacturers' products as supplied by SCIEX for incorporation into its equipment and does not imply any right and/or license to use or permit others to use such manufacturers' and/or their product names as trademarks. SCIEX warranties are limited to those express warranties provided at the time of sale or license of its products and are SCIEX’s sole and exclusive representations, warranties, and obligations. SCIEX makes no other warranty of any kind whatsoever, expressed or implied, including without limitation, warranties of merchantability or fitness for a particular purpose, whether arising from a statute or otherwise in law or from a course of dealing or usage of trade, all of which are expressly disclaimed, and assumes no responsibility or contingent liability, including indirect or consequential damages, for any use by the purchaser or for any adverse circumstances arising therefrom.
  • Reactos-Devtutorial.Pdf

    Reactos-Devtutorial.Pdf

    Developer Tutorials Developer Tutorials Next Developer Tutorials Table of Contents I. Newbie Developer 1. Introduction to ReactOS development 2. Where to get the latest ReactOS source, compilation tools and how to compile the source 3. Testing your compiled ReactOS code 4. Where to go from here (newbie developer) II. Centralized Source Code Repository 5. Introducing CVS 6. Downloading and configuring your CVS client 7. Checking out a new tree 8. Updating your tree with the latest code 9. Applying for write access 10. Submitting your code with CVS 11. Submitting a patch to the project III. Advanced Developer 12. CD Packaging Guide 13. ReactOS Architecture Whitepaper 14. ReactOS WINE Developer Guide IV. Bochs testing 15. Introducing Bochs 16. Downloading and Using Bochs with ReactOS 17. The compile, test and debug cycle under Bochs V. VMware Testing 18. Introducing VMware List of Tables 7.1. Modules http://reactos.com/rosdocs/tutorials/bk02.html (1 of 2) [3/18/2003 12:16:53 PM] Developer Tutorials Prev Up Next Chapter 8. Where to go from here Home Part I. Newbie Developer (newbie user) http://reactos.com/rosdocs/tutorials/bk02.html (2 of 2) [3/18/2003 12:16:53 PM] Part I. Newbie Developer Part I. Newbie Developer Prev Developer Tutorials Next Newbie Developer Table of Contents 1. Introduction to ReactOS development 2. Where to get the latest ReactOS source, compilation tools and how to compile the source 3. Testing your compiled ReactOS code 4. Where to go from here (newbie developer) Prev Up Next Developer Tutorials Home Chapter 1. Introduction to ReactOS development http://reactos.com/rosdocs/tutorials/bk02pt01.html [3/18/2003 12:16:54 PM] Chapter 1.
  • Detecting Exploit Code Execution in Loadable Kernel Modules

    Detecting Exploit Code Execution in Loadable Kernel Modules

    Detecting Exploit Code Execution in Loadable Kernel Modules HaizhiXu WenliangDu SteveJ.Chapin Systems Assurance Institute Syracuse University 3-114 CST, 111 College Place, Syracuse, NY 13210, USA g fhxu02, wedu, chapin @syr.edu Abstract and pointer checks can lead to kernel-level exploits, which can jeopardize the integrity of the running kernel. Inside the In current extensible monolithic operating systems, load- kernel, exploitcode has the privilegeto interceptsystem ser- able kernel modules (LKM) have unrestricted access to vice routines, to modify interrupt handlers, and to overwrite all portions of kernel memory and I/O space. As a result, kernel data. In such cases, the behavior of the entire sys- kernel-module exploitation can jeopardize the integrity of tem may become suspect. the entire system. In this paper, we analyze the threat that Kernel-level protection is different from user space pro- comes from the implicit trust relationship between the oper- tection. Not every application-level protection mechanism ating system kernel and loadable kernel modules. We then can be applied directly to kernel code, because privileges present a specification-directed access monitoring tool— of the kernel environment is different from that of the user HECK, that detects kernel modules for malicious code ex- space. For example, non-executableuser page [21] and non- ecution. Inside the module, HECK prevents code execution executable user stack [29] use virtual memory mapping sup- on the kernel stack and the data sections; on the bound- port for pages and segments, but inside the kernel, a page ary, HECK restricts the module’s access to only those kernel or segment fault can lead to kernel panic.
  • Fast Linux I/O in the Unix Tradition

    Fast Linux I/O in the Unix Tradition

    — preprint only: final version will appear in OSR, July 2008 — PipesFS: Fast Linux I/O in the Unix Tradition Willem de Bruijn Herbert Bos Vrije Universiteit Amsterdam Vrije Universiteit Amsterdam and NICTA [email protected] [email protected] ABSTRACT ory wall” [26]). To improve throughput, it is now essential This paper presents PipesFS, an I/O architecture for Linux to avoid all unnecessary memory operations. Inefficient I/O 2.6 that increases I/O throughput and adds support for het- primitives exacerbate the effects of the memory wall by in- erogeneous parallel processors by (1) collapsing many I/O curring unnecessary copying and context switching, and as interfaces onto one: the Unix pipeline, (2) increasing pipe a result of these cache misses. efficiency and (3) exploiting pipeline modularity to spread computation across all available processors. Contribution. We revisit the Unix pipeline as a generic model for streaming I/O, but modify it to reduce overhead, PipesFS extends the pipeline model to kernel I/O and com- extend it to integrate kernel processing and complement it municates with applications through a Linux virtual filesys- with support for anycore execution. We link kernel and tem (VFS), where directory nodes represent operations and userspace processing through a virtual filesystem, PipesFS, pipe nodes export live kernel data. Users can thus interact that presents kernel operations as directories and live data as with kernel I/O through existing calls like mkdir, tools like pipes. This solution avoids new interfaces and so unlocks all grep, most languages and even shell scripts.