User Space Device Drivers Introduction and Implementation using VGAlib library

Transcription

1 User Space Device Drivers Introduction and Implementation using VGAlib library Prabhat K. Saraswat Btech 6th Semester Information and Communication Technology Dhirubhai Ambani Institute of Information and Communication Technology (DA-IICT) Gandhinagar, Gujarat Abstract This paper contrasts between the basic architecture and utility of a User Space Device Driver over a Kernel Space Device Driver. It also seeks to give a brief overview of the working of a device driver. An implementation of a very basic User Space Device Driver is also done using Linux Framework for User Space Device Drivers. VGAlib, a user space graphics driver is also analyzed and the finer details are understood. The whole idea is to proxy device file callbacks in to user space, allowing the device files to be implemented by daemons instead of kernel code. The study is supplemented with a code written in C utilizing the User Space Device Driver, ie VGAlib. I. Introduction To understand about the basic difference between a Kernel Space and a User Space Device Driver, it is imperative to understand the functioning of two main types of devices available under all UNIX systems, which are character and block devices. Character devices are those for which no buffering is performed, and block devices are those which are accessed through a cache. Block devices must be random access, but character devices are not required to be, though some are. File Systems can only be mounted if they are on block devices. Character devices are read from and written to with two function calls, namely read and write. These calls do not return until the operation is complete. By contrast, block devices do not even implement the read and write functions, and instead have a function which is historically as well as strangely been called the ``strategy routine.'' Reads and writes are done through the buffer cache mechanism by some different generic functions. These functions go through the buffer cache, and so may or may not actually call the strategy routine, depending on whether or not the block requested is in the buffer cache (for reads) or on whether or not the buffer cache is full (for writes). A request can be asynchronous. A generic function can request the strategy routine to schedule reads that have not been asked for, and to do it asynchronously, in the background, in the hopes that they will be needed later. The sources for character devices are kept in drivers/char/, and the sources for block devices are kept in drivers/block/. They have similar interfaces, and are very much alike, except for reading and writing. Because of the difference in reading and writing, initialization is different, as block devices have to register a strategy routine, which is registered in a different way than the read and write routines of a character device driver. II. I/O subsystem and Devices in UNIX Devices by themselves are not intelligent, to control the devices and to make them do something meaningful leads to the need of development of device drivers. A device driver consists of a set of routines that control a peripheral device attached to a workstation. The operating system normally

2 provides a uniform interface to all peripheral devices. Linux and UNIX present peripheral devices at a sufficiently high level of abstraction by observing that a large proportion of I/O devices can be represented as a sequence of bytes. Linux and UNIX use the file--which is a well understood data structure for handling byte sequences--to represent I/O devices. The kernel is not a separate task under Linux. It is as if each process has a copy of the kernel. When a user process executes a system call, it does not transfer control to another process, but changes its execution mode from user to kernel mode. In kernel mode, while executing the system call, the process has access to the kernel address space, and through supporting functions it has access to the address space of the user executing the call. The Linux kernel implements a device-independent I/O system that serves all devices. A device driver provides the I/O system with a standard interface to the hardware, hiding the unique characteristics of the hardware device from the user to the greatest extent possible. The outline of the flow of execution of a system call within the Linux operating system is: 1. User invokes a System call. 2. Call is vectored through a stub in libc library. 3. Call expands to an assembly routine which contains the interrupt instruction 4. The interrupt instruction transfers the call to the kernel entry point 5. System call is executed When a system call is requested, the kernel transfers control to the appropriate device driver routine that executes on behalf of the calling user process. All devices look like files on a Linux system. In fact, the user-level interface to a device is called a ýspecial file These special files (often called device nodes) reside in the /dev directory. Below(Fig 1.1) is the snapshot of execution of ls in /dev. Fig 1.1 i.e. by invoking the command ls -l ttysl0 following status information is yielded: crw-rw-rw 1 root uucp 212, :24 ttysl0 This example indicates that: ttyslo is a block type device, the major number is 212, and minor device number 0 is assigned to the device. Major device numbers are used by the Linux system to map I/O requests to the driver code, thereby deciding which device driver to execute, when a user reads from or writes to the special file. The minor numbers are entirely under the control of the driver writer, and usually refer to ýsub-devicesý of the device. These sub-devices may be separate units attached to a controller. Thus, a disk device driver may, for example, communicate with a hardware controller (the device) which has several disk drives (sub-devices) attached. III. Device Drivers and Linux Operating System A device driver is a collection of subroutines and data within the kernel that constitutes the software interface to an I/O device. When the kernel recognizes that a particular action is required from the device, it calls the appropriate driver routine, which passes control from the user process to the driver routine. Control is returned to the user process when the driver routine has completed. A device driver may be shared simultaneously by user applications and must be protected to ensure its own integrity.

3 The relationship between device driver and the Linux system can be shown in a following way. Fig 1.2 A device driver provides the following features: A set of routines that communicate with a hardware device and provide a uniform interface to the operating system kernel. A self-contained component that can be added to, or removed from, the operating system dynamically. Management of data flow and c ontrol between user programs and a peripheral device. A user-defined section of the kernel that allows a program or a peripheral device to appear as a `` /dev '' device to the rest of the system's software. IV. Kernal Space vs User Space A Linux user process executes in a space isolated from critical system data and other user processes. This protected environment provides security to protect the process from mistakes in other processes. A normal device driver executes in kernel mode, which places few limits on its freedom of action. The driver is assumed to be correct and responsible. A driver has to be part of the kernel in order to service interrupts and access device hardware. A Device Driver Implemented in user space proxies device file callbacks into user-space, allowing device files to be implemented by daemons instead of kernel code. Despite being implemented in user-space, these devices can look and act just like any other file under /dev which is implemented by kernel callbacks. A user-space device driver can do many of the things that kernel drivers can t, such as perform a long-running computation, block while waiting for an event, or read files from the file system. Unlike kernel drivers, a User Space device driver can use other device drivers that is, access the network, talk to a serial port, get interactive input from the user, pop up GUI windows, or read from disks. User-space drivers implemented are much easier to debug; it is impossible for them to crash the machine, are easily traceable using tools such as gdb, and can be killed and restarted without rebooting even if they become corrupted. Another problem that comes up frequently in operating systems is contention for a single resource by multiple competing processes. In UNIX, it s the job of a device driver to coordinate access to such resources. By accepting requests from user processes and (for example) queuing and serializing them, it becomes safe for processes that know nothing about each other to make requests in parallel to the same resource. Of course, kernel drivers do this job already, but they typically operate on top of hardware directly. However, kernel drivers can t easily be layered on top of other device drivers. On the other hand the User Space Device Drivers can be easily layered on other drivers device drivers as it is not a kernel module. Typically, such layering is accomplished by system daemons. For example, the lpd daemon manages printers at a high level. Since it is a user-space process, it can access the physical printer devices using kernel device drivers (for example, using printer or network drivers). In User Space Device Drivers, a daemon/driver can create a standard device file which is accessible by any program that knows how to use the POSIX system call interface. USD Drivers receive the UID, GID, and process ID along with every file operation, allowing the same sorts of security policies to be implemented as would be possible with a real kernel driver.

4 It is not always necessary to write a device driver for a device, especially in applications where no two applications will compete for the device. The most useful example of this is a memory-mapped device, it can also be done with devices in I/O space (devices accessed with inb() and outb(), etc.). If your process is running as superuser (root), the mmap() call can be used to map some of the process memory to actual memory locations, by mmap()'ing a section of /dev/mem. When this mapping has been done, it is pretty easy to write and read from real memory addresses just as any other variables would have been read or written. If the driver needs to respond to interrupts, then working in kernel space is needed, also it is needed to write a real device driver, as there is no good way to deliver interrupts to user processes. VGAlib library A User Space Driver As a part of implementation and testing of User Space Driver, we implemented and used an interesting graphics package for linux system, which also happens to be a good example of a userspace driver is the VGAlib library. VGAlib is a low-level graphics library for Linux. It augments the C programming language, which doesn't provide support for graphics. The standard read() and write() calls are really inadequate for writing a really fast graphics driver, and so instead there is a library which acts conceptually like a device driver, but runs in user space. Any processes which use it must run setuid root, because it uses the ioperm() system call. It is possible for a process that is not setuid root to write to /dev/mem if there is a group mem or kmem which is allowed write permission to /dev/mem and the process is properly setgid, but only a process running as root can execute the ioperm() call. There are several I/O ports associated with VGA graphics. vgalib creates symbolic names for this with #define statements, and then issues the ioperm() call like this to make it possible for the process to read and write directly from and to those ports:

5 It only needs to do error checking once, because the only reason for the ioperm() call to fail is that it is not being called by the superuser, and this status is not going to change. After making this call, the process is allowed to use inb and outb machine instructions, but only on the specified ports. These instructions can be accessed without writing directly in assembly by including <linux/asm>. After arranging for port I/O, vgalib arranges for writing directly to kernel memory with the following code segment: It first opens /dev/mem, then allocates memory enough so that the mapping can be done on a page (4 KB) boundary, and then attempts the map. GRAPH_SIZE is the size of VGA memory, and GRAPH_BASE is the first address of VGA memory in /dev/mem. Then by writing to the address that is returned by mmap(), the process is actually writing to screen memory.

6 A simple code was written using the vgalib library: This code paints a single red pixel on the screen and after the interval of five seconds; it resets your console to text mode and will exit. Note our first statement, vga_init(). This initializes the VGAlib library. The second line, vga_setmode(g320x200x256), sets the screen to mode 5, which is 320x200x256. That is to say, screen becomes a grid which is 320 pixels wide, 200 pixels high, and which supports 256 colors. Alternatively, we could have written vga_setmode(5). Either statement is acceptable. Our next command, vga_setcolor(4), makes red the current color, though any value from 0 to 255 can be chosen. REFERENCES [1] Albinet, A. rlat, J. Fabre, J.-C., Characterization of the impact of faulty drivers on the robustness of the Linux kernel in 2004 International Conference on Dependable Systems and Networks, pp [2] Allessandro Rubini, Jonathan Corbet: Linux Device Drivers 2nd Edition, pp