[Linux设备驱动第三版]小记 [1-3章]

Chapter 1:

Device drivers are distinct “black boxes” that make a particular piece of hardware respond to a well-defined internal programming interface; they hide completely the details of how the device works.

 

User activities are performed by means of a set of standardized calls that are independent of the specific driver; mapping those calls to device-specific operations that acton real hardware is then the role of the device driver.

 

the role of a device driver is providing mechanism, not policy.

 

write kernel code to access the hardware, but don’t force particular policies on the user, since different users have different needs.leaving all the issues about how to use the hardware to the applications.

 

Driver: it is a software layer that lies between the applications and the actual device.

 

Each piece of code that can be added to the kernel at runtime is called a module.

 

Each module is made up of object code(not linked into a complete executable) that can be dynamically linked to the running kernel by the insmod program and can be unlinked by the rmmod program.

 

Driver is generally classifiable as a char module, a block module, or a network module.

 

A character (char) device is one that can be accessed as a stream of bytes (like a file);Such a driver usually implements at least the open, close, read, and write system calls.

 

block devices are accessed by filesystem nodes in the /dev directory. A block device is a device (e.g., a disk) that can host a filesystem.

 

 A network interface is in charge of sending and receiving data packets, driven by the network subsystem of the kernel. A network driver knows nothing about individual connections; it only handles packets. Communication between the kernel and a network device driver is completely different from that used with char and block drivers.

 

In the official kernel distribution, only an authorized user can load modules; the system call init_module checks if the
invoking process is authorized to load a module into the kernel.

 

Any input received from user processes should be treated with great suspicion; never trust it unless you can verify it.

 

Be careful with uninitialized memory; any memory obtained from the kernel should be zeroed or otherwise initialized before being made available to a user process or device. Otherwise, information leakage (disclosure of data, passwords, etc.) could result.

 

a maliciously modified kernel could allow anyone to load a module, thus opening an unexpected back door via init_module.

 

the even-numbered kernel versions (i.e., 2.6.x) are the stable ones that are intended for general distribution. The odd versions (such as 2.7.x), on the contrary, are development snapshots and are quite ephemeral.

 

This book covers Version 2.6 of the kernel. Our focus has been to show all the features available to device driver writers in 2.6.10.

 

The central gathering point for Linux kernel developers is the linux-kernel mailing list.

 

 

---

 

Chapter 2:

Regardless of the origin of your kernel, building modules for 2.6.x requires that you have a configured and built kernel tree on your system. 2.6 modules are linked against object files found in the kernel source tree; the result is a more robust module loader, but also the requirement that those object files be available.

 

Kernel hackers typically keep a “sacrificial” system around for the purpose of testing new code.

 

MODULE_LICENSE is used to tell the kernel that this module bears a free license; without such a declaration, the kernel complains when the module is loaded.

 

The printk function is de