Device drivers are an elementary part of the Linux kernel and comprise roughly 2/3 of the project's lines of code. Even though the fraction of device driver code in a conventional operating system (OS) can vary, some of these components are essential for system functioning. In addition, the Linux kernel is used in a wide range of applications, from cloud service providers to embedded systems and supercomputers. If GNU/Linux systems should be trustworthy to justify running them in those environments, then testing the kernel is fundamental. However, since device drivers are designed to interface with hardware, conventional test approaches may not suit the occasions when devices are unavailable at test time. This raises the question: How are device drivers tested?
TopIntroduction
Trusting Critical FOSS Components
The present chapter revolves around the theme of dependability in Free and Open Source Software (FOSS) systems, with a specific focus on Linux. The study highlights the significance of the FOSS infrastructure that underpins a substantial portion of the software and online systems we rely on for both business and personal purposes. The examination centers on Linux device drivers, serving as a representative case study to raise questions about the level of trust that can be placed in the FOSS ecosystem. The material conducts an exhaustive analysis of the software testing methodologies utilized by the Linux project to assess the quality and reliability of device drivers. This discussion sheds light on the transparency inherent in the FOSS model, as it offers a unique opportunity to inspect and scrutinize the internal workings of the software. This openness stands in contrast to the limited ability to examine proprietary products that drive mission-critical systems, which lack similar transparency.
Linux, as an enduring project, forms the foundation of a substantial portion of today's modern computational infrastructure, a fact that underscores its importance and widespread adoption. The success of Linux is attributed, in part, to the implementation of innovative business models that facilitate collaboration between individuals and organizations with diverse perspectives. This collaborative environment enables stakeholders to leverage shared resources while being actively encouraged to contribute back to the community through money investments and technological enhancements. The chapter presents a valuable exploration of the factors contributing to the positive reputation and resilience of the Linux ecosystem, underscoring the significance of effective strategies that foster cooperation and mutual support within the FOSS community.
Device Drivers
Device drivers are an elementary part of the Linux kernel and comprise roughly 2/31 of the project’s lines of code. Even though the fraction of device driver code in a conventional operating system (OS) can vary, some of these components are essential for system functioning. In addition, the Linux kernel is used in a wide range of applications, from cloud service providers to embedded systems and supercomputers (Corbet and Kroah-Hartman, 2017). If GNU/Linux systems should be trustworthy to justify running them in those environments, then testing the kernel is fundamental. However, since device drivers are designed to interface with hardware, conventional test approaches may not suit the occasions when devices are unavailable at test time. This bares the question: how are device drivers tested?
This chapter presents an introduction to Linux kernel device drivers, the Linux kernel development process, software test concepts, and popular 2 test tools for assessing device driver functionality.
Linux Kernel Device Drivers
The Linux kernel is accounted for many essential operating system tasks such as memory management, process scheduling, data storage, network communication, and many others (About Linux Kernel 2021). The kernel must operate several devices with highly distinct characteristics and complexity to provide fundamental system functionality. Moreover, it is reasonable to avoid mixing the control logic of different devices with one another and with core system logic. Thus, it is usual to encapsulate code for managing a device (or a family of related devices) into a device driver. “A driver is a piece of software whose aim is to control and manage a particular hardware device, hence the name device driver” (Madieu, 2017). For a more objective definition, let’s consider that a device driver is characterized by a well-delimited piece of code (usually a file or a few files) whose purpose is to control the operation of a hardware design (or a set of related hardware designs). Usually, hardware designs are described in documents called datasheets or blueprints, which in turn describe the components and operation of a hardware device.
Entire subsystems and kernel portions not restricted to the operation of a single device (or set of devices), e.g., file systems, network stack, process scheduler, memory manager, etc., are not device drivers. Although these components may contain device drivers, they are not device drivers.