Towards Documenting and Automating Collateral Evolutions in Linux Device Drivers

Collateral evolutions are a pervasive problem in Linux device driver development, due to the frequent evolution of Linux driver support libraries and APIs. Such evolutions are needed when an evolution in a driver support library affects the library's interface, entailing modifications in all dependent device-specific code. Currently, collateral evolutions in Linux are done nearly manually. The large number of Linux drivers, however, implies that this approach is time-consuming and unreliable, leading to subtle errors when modifications are not done consistently. In this paper, we describe the development of a language-based infrastructure, Coccinelle, with the goal of documenting and automating the kinds of collateral evolutions that occur in device driver code. Because Linux programmers are accustomed to manipulating program modifications in terms of patch files, we base our language on the patch syntax, extending patches to semantic patches

Towards Documenting and Automating Collateral Evolutions in Linux Device Drivers

Collateral evolutions are a pervasive problem in Linux device driver development, due to the frequent evolution of Linux driver support libraries and APIs. Such evolutions are needed when an evolution in a driver support library affects the library's interface, entailing modifications in all dependent device-specific code. Currently, collateral evolutions in Linux are done nearly manually. The large number of Linux drivers, however, implies that this approach is time-consuming and unreliable, leading to subtle errors when modifications are not done consistently. In this paper, we describe the development of a language-based infrastructure, Coccinelle, with the goal of documenting and automating the kinds of collateral evolutions that occur in device driver code. Because Linux programmers are accustomed to manipulating program modifications in terms of patch files, we base our language on the patch syntax, extending patches to semantic patches

Understanding Collateral Evolution in Linux Device Drivers

In a modern operating system (OS), device drivers can make up over 70% of the source code. Driver code is also heavily dependent on the rest of the OS, for functions and data structure defined in the kernel and driver support libraries. These two properties together pose a significant problem for OS evolution, as any changes in the interfaces exported by the kernel and driver support libraries can trigger a large number of adjustments in dependent drivers. These adjustments, which we refer to as collateral evolutions, may be complex, entailing substantial code reorganizations. Collateral evolution of device drivers is thus time consuming and error prone. In this paper, we present a qualitative and quantitative assessment of the collateral evolution problem in Linux device driver code. We provide a taxonomy of evolutions and collateral evolutions, and show that from one version of Linux to the next, collateral evolutions can account for up to 35% of the lines modified in such code. We then identify some of the challenges that must be met in the future to automate the collateral evolution process

The Impact of Generic Data Structures: Decoding the Role of Lists in the Linux Kernel

International audienceThe increasing adoption of the Linux kernel has been sustained by a large and constant maintenance effort, performed by a wide and heterogeneous base of contributors. One important problem that maintainers face in any code base is the rapid understanding of complex data structures. The Linux kernel is written in the C language, which enables the definition of arbitrarily uninformative datatypes, via the use of casts and pointer arithmetic, of which doubly linked lists are a prominent example. In this paper, we explore the advantages and disadvantages of such lists, for expressivity, for code understanding, and for code reliability. Based on our observations, we have developed a toolset that includes inference of descriptive list types and a tool for list visualization. Our tools identify more than 10,000 list fields and variables in recent Linux kernel releases and succeeds in typing 90%. We show how these tools could have been used to detect previously fixed bugs and identify 6 new ones

Ecole des Mines de

“Greg Kroah-Hartman has gotten [Linux] 2.6.13 off to a good start with a massive set of driver core patches. There are a fair number of API changes that come with this patch set, so the whole thing is worth a look. In-tree code has been fixed to use the new API, but, as always, maintainers of external code are on their own.

A Parts-of-file File System

International audienceThe Parts-of-file File System (PofFS) allows read-write accesses to different views of a given file or set of files in order to help the user separate and manipulate different concerns. The set of files is considered as a mount point from which views can be selected as read-write files via directories. Paths are formulas mentioning properties of a desired view. Each directory contain a file (the view) which contains the parts of the mounted files that satisfy the properties. This service is offered generically at the file system level, and a plug-in interface permits that file formats, or application-specific details are handled by user-defined operators. Special plug-ins called transducers can be defined for automatically attaching properties to parts of files. Performances are encouraging; files of 100 000 lines are handled efficiently

Un système de fichiers logique

International audienc

Logic file system (un système de fichier basé sur la logique)

Pour rechercher des documents numériques (musiques, e-mails, sources de programmes) les systèmes traditionnels, comme les systèmes de fichiers ou le Web, fournissent chacun des outils de navigation et d'interrogation, mais ne permettent pas de les combiner. La navigation est intuitive et progressive mais elle implique une classification des données rigide et unique. L'interrogation apporte flexibilité et expressivité, mais ne possède pas les avantages de la navigation. Pour manipuler le contenu de ces documents, d'autres outils existent mais ils souffrent des mêmes limitations. Nous proposons un nouveau paradigme pour les systèmes d'information basé sur la logique : le Logic File System (LFS), qui offre une organisation expressive, une recherche combinant interrogation et navigation, et une facilité de manipulation, à la fois des fichiers et de leurs contenus ; le tout d'une façon intégrée et mis en oeuvre au niveau système de fichier.RENNES1-BU Sciences Philo (352382102) / SudocRENNES-INRIA Rennes Irisa (352382340) / SudocSudocFranceF

A Logic File System

We present the new paradigm of logic file systems, its implementation, and first experimental results. It offers in an integrated way navigation and classification, the possibility of expressive queries, ease of use, and possible heterogeneity of data. This paradigm is object-centered. It associates logical descriptions to objects, and logical relations between descriptions serve as a basis for navigation and querying. We compare logic file systems with the hierarchical, boolean, and data-base paradigms. We present briefly the rôle of logic in logic file systems, and in more details the implementation issues of a particular logic file system that uses a simple logic

The Parts-of-file File System

We present a new way of managing file contents, its implementation and preliminary experimental results. The goal is to permit simultaneous read/writ- e accesses to different views on a file, in order to help in separating a user's concerns, even when they are not independent. Files are considered as mount point directories from which views on the files are accessible as subdirectories and files with read and write permissions. Views are designated with logical formulas describing desired properties of views. They contain those parts of the original file that satisfy the formulas. Properties are attached to parts of the file automatically via programs called transducers. A file system interface is used for querying views, navigating between views, and updating view contents