LDD 4 Linux Device Driver Basics - limingth/LASO GitHub Wiki

微内核 vs 宏内核
http://www.docin.com/p-462529976.html

2.4 LKM vs 2.6 LKM

http://hi.baidu.com/divinenotion/blog/item/fe91ab3b52892cee15cecb28.html

12.1.1. Linking Done In Kernel

The biggest change to LKMs between Linux 2.4 and Linux 2.6 is an internal one: LKMs get loaded much differently. Most people won't see any difference except that the suffix on a file containing an LKM has changed, because they use high level tools to manage the LKMs and the interface to those tools hasn't changed.

Before Linux 2.6, a user space program would interpret the ELF object (.o) file and do all the work of linking it to the running kernel, generating a finished binary image. The program would pass that image to the kernel and the kernel would do little more than stick it in memory. In Linux 2.6, the kernel does the linking. A user space program passes the contents of the ELF object file directly to the kernel. For this to work, the ELF object image must contain additional information. To identify this particular kind of ELF object file, we name the file with suffix ".ko" ("kernel object") instead of ".o" For example, the serial device driver that in Linux 2.4 lived in the file serial.o in Linux 2.6 lives in the file serial.ko.

So there is a whole new modutils package for use with Linux 2.6. In it, insmod is a trivial program, as compared to the full blown linker of the Linux 2.4 version.

Also, the procedure to build an LKM is somewhat harder. To make a .ko file, you start with a regular .o file. You run the program modpost (which comes with the Linux source code) on it to create a C source file that describes the additional sections the .ko file needs. We'll call this the .mod file because you conventionally include ".mod" in the file name.

You compile the .mod file and link the result with the original .o file to make a .ko file.

The .mod object file contains the name that the LKM instance will have when you load the LKM. You set that name with a -D compile option (when you compile the .mod file) that sets the KBUILD_MODNAME macro.

This change means some things are decidedly harder -- choosing the name for the LKM instance, for example. In Linux 2.4, the name was one of the inputs to the kernel. insmod decided on the name and passed it to the kernel. insmod's -o option told it explicitly what to use for the LKM instance name. But in 2.6, there is no such parameter on the system call and hence no -o option on insmod. The name is part of the ELF object (.o file) that you pass to the kernel. The default name is built into the ELF object, but if you want to load it with some other name, you must edit the ELF image before passing it to insmod.

VMALLOC_END: (在include/asm-arm/arch-dtt6c03a/vmalloc.h中定义）

VMALLOC_START: (具体算法在include/asm-arm/pgtable.h中定义)

PAGE_OFFSET: (在include/asm-arm/memory.h中定义)

TASK_SIZE: (在include/asm-arm/memory.h中定义)

设备号

当静态分配设备号时，需要查看系统中已经存在的设备号，从而决定使用哪个新设备号。可以读取/proc/devices文件获得设备的设备号。

/proc/devices文件包含字符设备和块设备的设备号。

现在的 Linux 内核允许多个驱动共享一个主设备号，但更多的设备都遵循一个驱动对一个主设备号的原则。

内核由次设备号确定当前所指向的是哪个设备。根据所编写的驱动程序，可以从内核那里得到一个直接指向设备的指针，或者使用次设备号作为一个设备本地数组的索引。但不论如何，内核自身几乎不知道次设备号的什么事情。

Linux的设备管理是和文件系统紧密结合的，各种设备都以文件的形式存放在/dev目录下，称为设备文件。应用程序可以打开、关闭和读写这些设备文件，完成对设备的操作，就像操作普通的数据文件一样。为了管理这些设备，系统为设备编了号，每个设备号又分为主设备号和次设备号。主设备号用来区分不同种类的设备，而次设备号用来区分同一类型的多个设备。对于常用设备，Linux有约定俗成的编号，如硬盘的主设备号是3。

一个字符设备或者块设备都有一个主设备号和次设备号。主设备号和次设备号统称为设备号。主设备号用来表示一个特定的驱动程序。次设备号用来表示使用该驱动程序的各设备。例如一个嵌入式系统，有两个LED指示灯，LED灯需要独立的打开或者关闭。那么，可以写一个LED灯的字符设备驱动程序，可以将其主设备号注册成5号设备，次设备号分别为1和2。这里，次设备号就分别表示两个LED灯。

申请和释放设备号

内核维护着一个特殊的数据结构，用来存放设备号与设备的关系。在安装设备时，应该给设备申请一个设备号，使系统可以明确设备对应的设备号。设备驱动程序中的很多功能，是通过设备号来操作设备的。

次设备号的主要用途

1、区分设备驱动程序控制的实际设备；

2、区分不同用途的设备 (misc 系列设备)

3、区分块设备的分区 (partition)

区分块设备的分区

块设备具有被称为分区的分配领域。例如，硬盘在物理上是一个设备，从内核的角度，硬盘被分为多个分区，而以这些分区为对象则形成了文件系统，此时，次设备号既表示设备，也表示分区。

在线查询 Linux 源码 http://os1a.cs.columbia.edu/lxr/ident?