Linux Device Drivers 2nd Edition (779877), страница 6
Текст из файла (страница 6)
A module uses the kernel through awell-defined interface, but is not part of it, similar to the way user programs usethe kernel through system calls. Note that the exemption to GPL licensing appliesonly to modules that use only the published module interface. Modules that digdeeper into the kernel must adhere to the “derived work” terms of the GPL.In brief, if your code goes in the kernel, you must use the GPL as soon as yourelease the code.
Although personal use of your changes doesn’t force the GPL onyou, if you distribute your code you must include the source code in the distribution — people acquiring your package must be allowed to rebuild the binary atwill. If you write a module, on the other hand, you are allowed to distribute it inbinary form. However, this is not always practical, as modules should in generalbe recompiled for each kernel version that they will be linked with (as explainedin Chapter 2, in the section “Version Dependency,” and Chapter 11, in the section“Version Control in Modules”).
New kernel releases — even minor stable releases —often break compiled modules, requiring a recompile. Linus Torvalds has statedpublicly that he has no problem with this behavior, and that binary modulesshould be expected to work only with the kernel under which they were compiled. As a module writer, you will generally serve your users better by makingsource available.As far as this book is concerned, most of the code is freely redistributable, eitherin source or binary form, and neither we nor O’Reilly & Associates retain any righton any derived works.
All the programs are available through FTP fromftp://ftp.ora.com/pub/examples/linux/drivers/, and the exact license terms are statedin the file LICENSE in the same directory.1222 June 2001 16:32http://openlib.org.uaOverview of the BookWhen sample programs include parts of the kernel code, the GPL applies: thecomments accompanying source code are very clear about that.
This only happensfor a pair of source files that are very minor to the topic of this book.Joining the Kernel DevelopmentCommunityAs you get into writing modules for the Linux kernel, you become part of a largercommunity of developers. Within that community, you can find not only peopleengaged in similar work, but also a group of highly committed engineers workingtoward making Linux a better system. These people can be a source of help, ofideas, and of critical review as well—they will be the first people you will likelyturn to when you are looking for testers for a new driver.The central gathering point for Linux kernel developers is the linux-ker nel mailinglist.
All major kernel developers, from Linus Torvalds on down, subscribe to thislist. Please note that the list is not for the faint of heart: traffic as of this writing canrun up to 200 messages per day or more. Nonetheless, following this list is essential for those who are interested in kernel development; it also can be a top-quality resource for those in need of kernel development help.To join the linux-kernel list, follow the instructions found in the linux-kernel mailing list FAQ: http://www.tux.org/lkml. Please read the rest of the FAQ while youare at it; there is a great deal of useful information there. Linux kernel developersare busy people, and they are much more inclined to help people who haveclearly done their homework first.Overview of the BookFrom here on, we enter the world of kernel programming.
Chapter 2 introducesmodularization, explaining the secrets of the art and showing the code for runningmodules. Chapter 3 talks about char drivers and shows the complete code for amemory-based device driver that can be read and written for fun. Using memoryas the hardware base for the device allows anyone to run the sample code withoutthe need to acquire special hardware.Debugging techniques are vital tools for the programmer and are introduced inChapter 4. Then, with our new debugging skills, we move to advanced features ofchar drivers, such as blocking operations, the use of select, and the important ioctlcall; these topics are the subject of Chapter 5.Before dealing with hardware management, we dissect a few more of the kernel’ssoftware interfaces: Chapter 6 shows how time is managed in the kernel, andChapter 7 explains memory allocation.1322 June 2001 16:32http://openlib.org.uaChapter 1: An Introduction to Device DriversNext we focus on hardware.
Chapter 8 describes the management of I/O ports andmemory buffers that live on the device; after that comes interrupt handling, inChapter 9. Unfortunately, not everyone will be able to run the sample code forthese chapters, because some hardware support is actually needed to test the software interface to interrupts. We’ve tried our best to keep required hardware support to a minimum, but you still need to put your hands on the soldering iron tobuild your hardware “device.” The device is a single jumper wire that plugs intothe parallel port, so we hope this is not a problem.Chapter 10 offers some additional suggestions about writing kernel software andabout portability issues.In the second part of this book, we get more ambitious; thus, Chapter 11 startsover with modularization issues, going deeper into the topic.Chapter 12 then describes how block drivers are implemented, outlining theaspects that differentiate them from char drivers.
Following that, Chapter 13explains what we left out from the previous treatment of memory management:mmap and direct memory access (DMA). At this point, everything about char andblock drivers has been introduced.The third main class of drivers is introduced next. Chapter 14 talks in some detailabout network interfaces and dissects the code of the sample network driver.A few features of device drivers depend directly on the interface bus where theperipheral fits, so Chapter 15 provides an overview of the main features of the busimplementations most frequently found nowadays, with a special focus on PCI andUSB support offered in the kernel.Finally, Chapter 16 is a tour of the kernel source: it is meant to be a starting pointfor people who want to understand the overall design, but who may be scared bythe huge amount of source code that makes up Linux.1422 June 2001 16:32http://openlib.org.uaCHAPTER TWOBUILDING ANDRUNNING MODULESIt’s high time now to begin programming.
This chapter introduces all the essentialconcepts about modules and kernel programming. In these few pages, we buildand run a complete module. Developing such expertise is an essential foundationfor any kind of modularized driver. To avoid throwing in too many concepts atonce, this chapter talks only about modules, without referring to any specificdevice class.All the kernel items (functions, variables, header files, and macros) that are introduced here are described in a reference section at the end of the chapter.For the impatient reader, the following code is a complete “Hello, World” module(which does nothing in particular).
This code will compile and run under Linuxkernel versions 2.0 through 2.4.*#define MODULE#include <linux/module.h>int init_module(void) { printk("<1>Hello, world\n"); return 0; }void cleanup_module(void) { printk("<1>Goodbye cruel world\n"); }The printk function is defined in the Linux kernel and behaves similarly to thestandard C library function printf.
The kernel needs its own printing functionbecause it runs by itself, without the help of the C library. The module can callprintk because, after insmod has loaded it, the module is linked to the kernel andcan access the kernel’s public symbols (functions and variables, as detailed in thenext section). The string <1> is the priority of the message. We’ve specified a highpriority (low cardinal number) in this module because a message with the defaultpriority might not show on the console, depending on the kernel version you are* This example, and all the others presented in this book, is available on the O’Reilly FTPsite, as explained in Chapter 1.1522 June 2001 16:34http://openlib.org.uaChapter 2: Building and Running Modulesrunning, the version of the klogd daemon, and your configuration.
You can ignorethis issue for now; we’ll explain it in the section “printk” in Chapter 4.You can test the module by calling insmod and rmmod, as shown in the screendump in the following paragraph. Note that only the superuser can load andunload a module.The source file shown earlier can be loaded and unloaded as shown only if therunning kernel has module version support disabled; however, most distributionspreinstall versioned kernels (versioning is discussed in “Version Control in Modules” in Chapter 11).