Loupe: Driving the Development of OS Compatibility Layers

TL;DR

Loupe is a dynamic analysis method that helps OS developers efficiently identify and implement only the necessary OS features to support a set of applications, significantly reducing engineering effort.

Contribution

It introduces Loupe, a novel dynamic analysis approach that guides OS compatibility layer development by accurately pinpointing essential OS features for application support.

Findings

Loupe reduces the number of system calls needed for compatibility.

Applying Loupe saved significant engineering effort in OS development.

Only a fraction of static analysis reported system calls are needed for application support.

Abstract

Supporting mainstream applications is fundamental for a new OS to have impact. It is generally achieved by developing a layer of compatibility allowing applications developed for a mainstream OS like Linux to run unmodified on the new OS. Building such a layer, as we show, results in large engineering inefficiencies due to the lack of efficient methods to precisely measure the OS features required by a set of applications. We propose Loupe, a novel method based on dynamic analysis that determines the OS features that need to be implemented in a prototype OS to bring support for a target set of applications and workloads. Loupe guides and boosts OS developers as they build compatibility layers, prioritizing which features to implement in order to quickly support many applications as early as possible. We apply our methodology to 100+ applications and several OSes currently under development, demonstrating high engineering effort savings vs. existing approaches: for example, for the 62 applications supported by the OSv kernel, we show that using Loupe, would have required implementing only 37 system calls vs. 92 for the non-systematic process followed by OSv developers. We study our measurements and extract novel key insights. Overall, we show that the burden of building compatibility layers is significantly less than what previous works suggest: in some cases, only as few as 20% of system calls reported by static analysis, and 50% of those reported by naive dynamic analysis need an implementation for an application to successfully run standard benchmarks.