LSKA 2010 Survey Report I Device Drivers & Cloud Computing

LSKA 2010 Survey Report I Device Drivers & Cloud Computing Yu Huang and Hao-Chung Yang {r98922015, r98944016}@csie.ntu.edu.tw Department of Computer Science and Information Engineering March 31, 2010 Abstract There are two topics among our interests to Linux kernel: device drivers and cloud computing. We hope that we can learn more about these two topics through the survey of LSKA. And finally we can decide what to implement in our final project. 1 Introduction Implementing Device Drivers It is important for engineers to understand the architecture of device drivers. As in the first chapter of Linux Device Drivers, by Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman, written about the importance of understanding device drivers, The Linux kernel remains a large and complex body of code, however, and would-be kernel hackers need an entry point where they can approach the code without being overwhelmed by complexity. Often, device drivers provide that gateway. Moreover, it will benefits us when we are going to write drivers some day in the future as more and more new hardware become available. 1

2 Architecture The simple procedure is that applications communicate with kernel through system calls and then communicate with device drivers through virtual file system (VFS). The architecture of kernel and device are depicted in figure (1) and a split view of kernel is depicted in figure (2). Figure 1: Architecture of Linux device driver. 2.1 Device driver types From figure (1) we can see there are three types of device drivers when we distinguish them in the view of device types: Character device driver A character (char) device is one that can be accessed like a file, that is, it can be accessed as a stream of bytes, thus a character device driver is responsible of implementing this behavior. This kind of driver usually 2

Figure 2: A split view of kernel. implements system calls like open, close, read, and write. Well-known examples of char driver are the text console (/dev/console), the serial port (/dev/ttys0 ), etc. Char devices can be accessed like a regular file, but they are just data channels that can only be accessed sequentially, which means that we can not move back and forth in a device file unlike in regular files. Block device driver A block device is a device that can host a filesystem. For example, a disk. Block devices are also accessed by filesystem nodes in the /dev/ directory like char devices. The main difference between block devices and char devices is the interface to the kernel. 3

Network device driver Network interfaces are devices that exchange data with other hosts; they are in charge of sending and receiving data packets. A network interface is not stream-oriented which means it knows nothing about individual connections but only deals with the transmission and receipt of packets. Unlike char devices and block devices, a network interface is not mapped to a node of filesystem. Therefore they can not be accessed through editing it like a regular file. 2.2 Device file As introduces above, we view each device as a file, so called device file or special file. And we communicate with devices through these files. Figure (3) shows the examples of device files. Figure 3: examples of device file. As shown in figure (3), if the first bit of the attribute of device files is c means that it is a char device file, otherwise if the first bit is b means it s a block device file. Each device file contains a major number and a minor number. The major number identifies the driver associated with the device while the minor number specifies its child devices. For example, different 4

sections on a disk has the same major number but different minor number. The device files are stored in /dev directory. And each device should be registered to kernel, and thus a major number is assigned to the specified device file. Registered devices are visible in /proc/devices; here can be used to find available major numbers. When user opens the device file, kernel will find the corresponding device driver according the the major number. The interaction of user and kernel to access device is depicted in figure (4). Figure 4: interaction between user and kernel. The kernel uses structure file operations, also known as fops, to access driver s function. The members of fops are function pointers, which points to system calls. That is, we implement the virtual file system using structure fops. And the member pointers are pointers point to implementations of system calls. The structure fops is shown in figure (5). 5

Figure 5: file operations structure. 3 Procedure In this section, we are going to describe how to implement device drivers. There are two perspectives in one device drivers: virtual device drivers and physical device drivers. Virtual device driver To implement a device driver we need to implement the virtual device driver which includes implementation of virtual file system (VFS) and also the system call interface. The goal of virtual device driver is to design drivers with good mechanism and behavior using Linux application interfaces (APIs). In general, there three steps to implement virtual device drivers: 1. define file operations As introduced above, file operations is the way for kernel to access 6

driver s function. Thus in order to implement device drivers, the first step is to define file operations. 2. implement system calls After the definition procedure, we thus need to implement system calls. While after the function register chrdev, the functions to implement system calls are defined through fops. And we called the implementation functions as driver method. 3. driver register (VFS) Device drivers register fops into kernel through function call: register chrdev(), and then fops becomes the entry for driver methods. The function register chrdev() needs three parameters: major - the major number of the registering device name - the name of the device fops - the file operation of the device driver After the registration, the defined fops is added into VFS. Therefore user applications need to call driver methods through device files. Physical device driver In addition to virtual device drivers, we also need to implement the physical device driver which controls physical device through hardware interface. The difficulty of designing a physical device driver is to discuss about how to control hardware through I/O port or I/O memory, that is, communication with chipsets. The key points of designing physical device driver is to check datasheets of chipsets, and control the hardware through control register of chipsets. Theoretically, we can classify registers of chipsets into three categories: 1. data registers - stores data in chipsets 2. control registers - control the behavior of chipsets 3. status registers - reserve the current status of chipsets 7

In order to implement physical device drivers, at first we need to write datasheets of chipsets as header files in C, usually this file can be attained from vendor. After that, we need to define a set of I/O functions to control registers. We call this set of functions as I/O wrapper function. Usually I/O wrapper functions are written by redefinition of existing functions like readb(), writedb(), inb(), outb(), etc. At last, use I/O wrapper functions to implement series of control functions, these functions are called chipset control functions. Chipset control functions are called by driver methods mentioned above. Thus to implement physical device driver sometimes need to rewrite driver methods. Figure 6: a simple example of procedure. A simple example of the whole procedure is shown in figure (6). The main key to design a good device driver is to implement a good virtual device driver while physical device drivers always look alike. In this survey we emphasize our target on character device drivers which is purely concerned with Linux kernel unlike network device drivers concerning too specific network understandings. We hope that we can be familiar with Linux kernel much more through taking a deep look into character de- 8

vice drivers. 4 Future work In the next survey, we are going to present a simple implemented character device driver. That is, to implement some main functions related to the device driver. Our aim in the final project is to develop our own device driver of a certain hardware. We have not decided what hardward yet, but we will decide before the next survey. Gathering informations about the specified hardward is also important for implementing device drivers as introduced in the section of physical device driver. Therefore in the next survey, we will also present the information about our target hardware. Cloud Computing Eucalyptus: An Open-source Infrastructure for Cloud Computing 1 Introduction Eucalyptus is an open source software framework for cloud computing that implements what is commonly referred to as Infrastructure as a Service (IaaS). This is infrastructure software that enables enterprises and government agencies to establish their own cloud computing environments. It is also a cloud-computing framework that uses computational and storage infrastructure commonly available to academic research groups to provide a platform that is modular and open to experimental instrumentation and study. Eucalyptus stands for Elastic Utility Computing Architecture Linking Your Programs To Useful Systems. The basic principles of the EUCALYP- TUS design are to be portable, modular and simple to use. Systems give users the ability to run and control entire virtual machine instances deployed across a variety physical resources. 9

Figure 7: The Eucalyptus architecture. 2 Related work Machine virtualization projects producing Virtual Machine (VM) hypervisor software have enabled new mechanisms for providing resources to users. The current implementation of the system uses Xen-based virtualization as its initial target hypervisor, but plan to add support for KVM/QEMU, VMware, and others in the near future. The commercial cloud computing offerings such as Amazon EC2/S3, Google AppEngine, esforce.com, etc, which maintain a proprietary infrastructure with open interfaces, there are open source projects aimed at resource provisioning with the help of virtualization. 10

The external interface to EUCALYPTUS is based on an already popular API developed by Amazon. The system allows users to start, control, access, and terminate entire virtual machines using an emulation of Amazon EC2s SOAP and Query interfaces. That is, users of EUCALYPTUS interact with the system using the exact same tools and interfaces that they use to interact with Amazon EC2. 3 EUCALYPTUS Design Figure 8: The controllers of Eucalyptus architecture. The architecture consists of four major parts: Node Controller, Cluster Controller, Storage Controller, and Cloud Controller. Node Controller A Node Controller (NC) executes on every node that is designated for hosting VM instances. An NC queries and controls the system software on its node (i.e., the host operating system and the hypervisor) 11

in response to queries and control requests from its Cluster Controller. An NC makes queries to discover the nodes physical resources V the number of cores, the size of memory, the available disk space V as well as to learn about the state of VM instances on the node. The information thus collected is propagated up to the Cluster Controller in responses to describeresource and describe-instances requests. The NC executes the request with the assistance of the hypervisor. To start an instance, the NC makes a node-local copy of the instance image files (the kernel, the root file system, and the ramdisk image), either from a remote image repository or from the local cache, creates a new endpoint in the virtual network overlay, and instructs the hypervisor to boot the instance. Virtual Network Overlay The Cluster Controller (CC) generally executes on a cluster front-end machine, or any machine that has network connectivity to both the nodes running NCs and to the machine running the Cloud Controller (CLC). CC has three primary functions: schedule incoming instance run requests to specific NCs, control the instance virtual network overlay, and gather/report information about a set of NCs. Cluster Controller Perhaps one of the most interesting challenges in the design of a cloud computing infrastructure is that of VM instance interconnectivity. When designing EUCALYPTUS, we recognized that the VM instance network solution must address connectivity, isolation, and performance. Every virtual machine that EUCALYPTUS controls must have network connectivity to each other, and at least partially to the public Internet. In a cloud shared by different users, VMs belonging to a single cloud allocation must be able to communicate, but VMs belonging to separate allocations must be isolated. The CC acts as a router between VM subnets, with the default policy blocking all IP traffic between VM networks. In this way, each set of VMs within a given named network 12

is isolated from VMs on a different named network at using VLANs, and further using IP subnetting. Storage Controller (Walrus) EUCALYPTUS includes Walrus, a data storage service that leverages standard web services technologies (Axis2, Mule) and is interface compatible with Amazons Simple Storage Service (S3). Walrus implements the REST (via HTTP), sometimes termed the Query interface, as well as the SOAP interfaces that are compatible with S3. Walrus provides two types of functionality. Users that have access to EUCALYPTUS can use Walrus to stream data into/out of the cloud as well as from instances that they have started on nodes. Walrus acts as a storage service for VM images. Root file system as well as kernel and ramdisk images used to instantiate VMs on nodes can be uploaded to Walrus and accessed from nodes. VM root file system, kernel and ramdisk images are packaged and uploaded using standard EC2 tools provided by Amazon. These tools compress images, encrypt them using user credentials, and split them into multiple parts that are described in an image description file. When a node controller (NC) requests an image from Walrus before instantiating it on a node, it sends an image download request that is authenticated using an internal set of credentials. Then, images are verified and decrypted, and finally transferred. Walrus is designed to be modular such that the authentication, streaming and back-end storage subsystems can be customized by researchers to fit their needs. Cloud Controller The underlying virtualized resources that comprise a EUCALYPTUS 13

cloud are exposed and managed by, the Cloud Controller (CLC). The CLC is a collection of web services which are best grouped by their roles into three categories: Figure 9: The architecture of cloud controller. Resource Services perform system-wide arbitration of resource allocations, let users manipulate properties of the virtual machines and networks, and monitor both system components and virtual resources. The Resource services process user virtual machine control requests and interact with the CCs to effect the allocation and deallocation of physical resources. Data Services govern persistent user and system data and provide for a configurable user environment for formulating resource allocation request properties. It handles the creation, modification, interrogation, and storage of stateful system and user data. Users can query these services to discover available resource information (images and clusters) and manipulate abstract parameters (keypairs, security groups, and network definitions) applicable to virtual machine and network allocations. 14

Interface Services present user-visible interfaces, handling authentication & protocol translation, and expose system management tools providing. The Interface tier also offers a Web interface for cloud users and administrators. Using a Web browser, users can sign up for cloud access, download the cryptographic credentials needed for the programmatic interface, and query the system, e.g., about available disk images. The administrators can, additionally, manage user accounts, inspect the availability of system components. Figure 10: User view of CLC interface. Figure 11: Administrator view of CLC interface. 15

References [1] Linux Device Driver, 3rd edition, http://lwn.net/kernel/ldd3/ [2] Linux Device Driver by Jollen http://www.jollen.org/linuxdevicedriver/ [3] Advanced Linux Programming, by CodeSourcery LLC http://www.advancedlinuxprogramming.com/ [4] an OpenMoko Free Training by OpenMoko coreteam http://jserv.sayya.org/kernel/linux device driver openlab.pdf [5] The Eucalyptus Open-source Cloud-computing System, by Daniel Nurmi, Rich Wolski, Chris Grzegorczyk, Graziano Obertelli, Sunil Soman, Lamia Youseff, Dmitrii Zagorodnov, in Proceedings of 9th IEEE International Symposium on Cluster Computing and the Grid, Shanghai, China. [6] Eucalyptus website: http://open.eucalyptus.com/ 16