Embedded Linux Primer: A Practical, Real-World Approach

  perror('read failed');
  close(fd);
  exit(-1);
 }
 printf('%s: read: returning %d bytes!
', argv[0], rc);
 close(fd);
 return 0;
}

This simple file, compiled on an ARM XScale system, demonstrates the binding of application to device driver, through the device node. Like the device driver, it doesn't do any useful work, but it does demonstrate the concepts as it exercises some of the methods we introduced in the device driver of Listing 8-10.

First we issue an open() system call[67] on our device node created earlier. If the open succeeds, we indicate that with a message to the console. Next we issue a read() command and again print a message to the console on success. Notice that a read of 0 bytes is perfectly acceptable as far as the kernel is concerned and, in actual practice, indicates an end-of-file or out-of-data condition. Your device driver defines that special condition. When complete, we simply close the file and exit. Listing 8-12 captures the output of running this example application on an ARM XScale target:

Listing 8-12. Using the Example Driver

$ modprobe hello1
Hello Example Init - debug mode is disabled
Hello: registered module successfully!
$ ./use-hello
./use-hello: entered
./use-hello: open: successful
./use-hello: read: returning zero bytes!
$

8.5. Device Drivers and the GPL

Much discussion and debate surrounds the issue of device drivers and how the terms of the GNU Public License apply to device drivers. The first test is well understood: If your device driver (or any software, for that matter) is based, even in part, on existing GPL software, it is called a derived work. For example, if you start with a current Linux device driver and modify it to suit your needs, this is certainly considered a derived work, and you are obligated to license this modified device driver under the terms of the GPL, observing all its requirements.

This is where the debate comes in. First, the disclaimer. This is not a legal opinion, and the author is not a lawyer. Some of these concepts have not been tested in court as of this writing. The prevailing opinion of the legal and open source communities is that if a work can be proven[68] to be independently derived, and a given device driver does not assume 'intimate knowledge' of the Linux kernel, the developers are free to license it in any way they see fit. If modifications are made to the kernel to accommodate a special need of the driver, it is considered a derived work and, therefore, is subject to the GPL.

A large and growing body of information exists in the open source community regarding these issues. It seems likely that, at some point in the future, these concepts will be tested in a court of law and precedent will be established. How long that might take is anyone's guess. If you are interested in gaining a better understanding of the legal issues surrounding Linux and open source, you might enjoy www.open-bar.org.

8.6. Chapter Summary

This chapter presented a high-level overview of device driver basics and how they fit into the architecture of a Linux system. Armed with the basics, readers new to device drivers can jump into one of the excellent texts devoted to device driver writers. Consult Section 8.6.1 for references.

• Device drivers enforce a rational separation between unprivileged user applications and critical kernel resources such as hardware and other devices, and present a well-known unified interface to applications.

• The minimum infrastructure to load a device driver is only a few lines of code. We presented this minimum infrastructure and built on the concepts to a simple shell of a driver module.

• Device drivers configured as loadable modules can be inserted into and removed from a running kernel after kernel boot.

• Module utilities are used to manage the insertion, removal, and listing of device driver modules. We covered the details of the module utilities used for these functions.

• Device nodes on your file system provide the glue between your userspace application and the device driver.

• Driver methods implement the familiar open, read, write, and close functionality commonly found in UNIX/Linux device drivers. This mechanism was explained by example, including a simple user application to exercise these driver methods.

• We concluded this chapter with an introduction to the relationship between kernel device drivers and the Open Source GNU Public License.

8.6.1. Suggestions for Additional Reading

Linux Device Drivers, 3rd Edition

Alessandro Rubini and Jonathan Corbet

O'Reilly Publishing, 2005

Filesystem Hierarchy Standard

Edited by Rusty Russel, Daniel Quinlan, and Christopher Yeoh

The File Systems Hierarchy Standards Group

www.pathname.com/fhs/

Rusty's Linux Kernel Page

Module Utilities for 2.6

Rusty Russell

http://kernel.org/pub/linux/kernel/people/rusty/  

Chapter 9. File Systems