1. linux中ioremap和mmap的区别
你不是已经说了区别
ioremap是将物理地址转换为虚拟地址
mmap是将设备内存线性地址映射到用户地址空间
linux的线程只能访问虚拟地址，不管是不是内核，ioremap应用，比如有个寄存器地址是0xe8000000
你要用ioremap映射后，才能访问地址0xe8000000。这两个地址是不同的，mmu会帮你搞定，对你是透明的
mmap在内核我用过ops中的mmap方法
我写过一个例程，见附件。里面还有用户态的测试程序。
2. linux共享内存和mmap的区别
共享内存的创建
根据理论：
1. 共享内存允许两个或多个进程共享一给定的存储区，因为数据不需要来回复制，所以是最快的一种进程间通信机制。共享内存可以通过mmap()映射普通文件（特殊情况下还可以采用匿名映射）机制实现，也可以通过系统V共享内存机制实现。应用接口和原理很简单，内部机制复杂。为了实现更安全通信，往往还与信号灯等同步机制共同使用。
mmap的机制如：就是在磁盘上建立一个文件，每个进程存储器里面，单独开辟一个空间来进行映射。如果多进程的话，那么不会对实际的物理存储器（主存）消耗太大。
shm的机制：每个进程的共享内存都直接映射到实际物理存储器里面。
结论：
1、mmap保存到实际硬盘，实际存储并没有反映到主存上。优点：储存量可以很大（多于主存）（这里一个问题，需要高手解答,会不会太多拷贝到主存里面？？？）；缺点：进程间读取和写入速度要比主存的要慢。
2、shm保存到物理存储器（主存），实际的储存量直接反映到主存上。优点，进程间访问速度（读写）比磁盘要快；缺点，储存量不能非常大（多于主存）
使用上看：如果分配的存储量不大，那么使用shm；如果存储量大，那么使用shm。
参看网络：http://ke..com/view/1499209.htm
mmap就是一个文件操作
看这些网络的描述：
mmap()系统调用使得进程之间通过映射同一个普通文件实现共享内存。普通文件被映射到进程地址空间后，进程可以向访问普通内存一样对文件进行访问，不必再调用read()，write（）等操作。 成功执行时，mmap()返回被映射区的指针，munmap()返回0。失败时，mmap()返回MAP_FAILED[其值为(void *)-1]，munmap返回-1。errno被设为以下的某个值 EACCES：访问出错EAGAIN：文件已被锁定，或者太多的内存已被锁定EBADF：fd不是有效的文件描述词EINVAL：一个或者多个参数无效 ENFILE：已达到系统对打开文件的限制ENODEV：指定文件所在的文件系统不支持内存映射ENOMEM：内存不足，或者进程已超出最大内存映射数量 EPERM：权能不足，操作不允许ETXTBSY：已写的方式打开文件，同时指定MAP_DENYWRITE标志SIGSEGV：试着向只读区写入 SIGBUS：试着访问不属于进程的内存区参数fd为即将映射到进程空间的文件描述字，
一般由open()返回，同时，fd可以指定为-1，此时须指定 flags参数中的MAP_ANON，表明进行的是匿名映射（不涉及具体的文件名，避免了文件的创建及打开，很显然只能用于具有亲缘关系的进程间通信）
相关文章参考：
mmap函数是unix/linux下的系统调用，来看《Unix Netword programming》卷二12.2节有详细介绍。
mmap系统调用并不是完全为了用于共享内存而设计的。它本身提供了不同于一般对普通文件的访问方式，进程可以像读写内存一样对普通文件的操作。而Posix或系统V的共享内存IPC则纯粹用于共享目的，当然mmap()实现共享内存也是其主要应用之一。
mmap系统调用使得进程之间通过映射同一个普通文件实现共享内存。普通文件被映射到进程地址空间后，进程可以像访问普通内存一样对文件进行访问，不必再 调用read()，write（）等操作。mmap并不分配空间, 只是将文件映射到调用进程的地址空间里, 然后你就可以用memcpy等操作写文件, 而不用write()了.写完后用msync()同步一下, 你所写的内容就保存到文件里了. 不过这种方式没办法增加文件的长度, 因为要映射的长度在调用mmap()的时候就决定了.
简单说就是把一个文件的内容在内存里面做一个映像，内存比磁盘快些。
基本上它是把一个档案对应到你的virtual memory 中的一段，并传回一个指针。
重写总结：
1、mmap实际就是操作“文件”。
2、映射文件，除了主存的考虑外。shm的内存共享，效率应该比mmap效率要高（mmap通过io和文件操作，或“需要写完后用msync()同步一下”）；当然mmap映射操作文件，比直接操作文件要快些;由于多了一步msync应该可以说比shm要慢了吧？？？
3、另一方面，mmap的优点是，操作比shm简单（没有调用比shm函数复杂），我想这也是许多人喜欢用的原因，包括nginx。
缺点，还得通过实际程序测试，确定！！！
修正理解（这也真是的，这个网站没办法附加；只能重写了）：
今天又细心研究了一下，发现网络这么一段说明：
2、系统调用mmap()用于共享内存的两种方式：
（1）使用普通文件提供的内存映射：适用于任何进程之间；此时，需要打开或创建一个文件，然后再调用mmap()；典型调用代码如下：
fd=open(name, flag, mode);
if(fd<0)
...
ptr=mmap(NULL, len , PROT_READ|PROT_WRITE, MAP_SHARED , fd , 0); 通过mmap()实现共享内存的通信方式有许多特点和要注意的地方，我们将在范例中进行具体说明。
（2）使用特殊文件提供匿名内存映射：适用于具有亲缘关系的进程之间；由于父子进程特殊的亲缘关系，在父进程中先调用mmap()，然后调用fork()。那么在调用fork()之后，子进程继承父进程匿名映射后的地址空间，同样也继承mmap()返回的地址，这样，父子进程就可以通过映射区域进行通信了。注意，这里不是一般的继承关系。一般来说，子进程单独维护从父进程继承下来的一些变量。而mmap()返回的地址，却由父子进程共同维护。
看了一下windows“内存映射文件”：http://ke..com/view/394293.htm
内存映射文件与虚拟内存有些类似，通过内存映射文件可以保留一个地址空间的区域，同时将物理存储器提交给此区域，只是内存文件映射的物理存储器来自一个已经存在于磁盘上的文件，而非系统的页文件，而且在对该文件进行操作之前必须首先对文件进行映射，就如同将整个文件从磁盘加载到内存。由此可以看出，使用内存映射文件处理存储于磁盘上的文件时，将不必再对文件执行I/O操作，这意味着在对文件进行处理时将不必再为文件申请并分配缓存，所有的文件缓存操作均由系统直接管理，由于取消了将文件数据加载到内存、数据从内存到文件的回写以及释放内存块等步骤，使得内存映射文件在处理大数据量的文件时能起到相当重要的作用。另外，实际工程中的系统往往需要在多个进程之间共享数据，如果数据量小，处理方法是灵活多变的，如果共享数据容量巨大，那么就需要借助于内存映射文件来进行。实际上，内存映射文件正是解决本地多个进程间数据共享的最有效方法。
这里再总结一次：
1、mmap有两种方式，一种是映射内存，它把普通文件映射为实际物理内存页，访问它就和访问物理内存一样（这也就和shm的功能一样了）（同时不用刷新到文件）
2、mmap可以映射文件，不确定会不会像windows“内存映射文件”一样的功能，如果是，那么他就能映射好几G甚至好几百G的内存数据，对大数据处理将提供强大功能了？？？
3、shm只做内存映射，和mmap第一个功能一样！只不过不是普通文件而已，但都是物理内存。
3. Linux驱动程序的工作原理
由于你的问题太长我只好转载别人的手打的太累不好意思~~~
Linux是Unix***作系统的一种变种,在Linux下编写驱动程序的原理和
思想完全类似于其他的Unix系统,但它dos或window环境下的驱动程序有很大的
区别.在Linux环境下设计驱动程序,思想简洁,***作方便,功芤端口芮看?但是
支持函数少,只能依赖kernel中的函数,有些常用的***作要自己来编写,而且调
试也不方便.本人这几周来为实验室自行研制的一块多媒体卡编制了驱动程序,
获得了一些经验,愿与Linux fans共享,有不当之处,请予指正.
以下的一些文字主要来源于khg,johnsonm的Write linux device driver,
Brennan's Guide to Inline Assembly,The Linux A-Z,还有清华BBS上的有关
device driver的一些资料. 这些资料有的已经过时,有的还有一些错误,我依
据自己的试验结果进行了修正.
一. Linux device driver 的概念
系统调用是***作系统内核和应用程序之间的接口,设备驱动程序是***作系统
内核和机器硬件之间的接口.设备驱动程序为应用程序屏蔽了硬件的细节,这样
在应用程序看来,硬件设备只是一个设备文件, 应用程序可以象***作普通文件
一样对硬件设备进行***作.设备驱动程序是内核的一部分,它完成以下的功能:
1.对设备初始化和释放.
2.把数据从内核传送到硬件和从硬件读取数据.
3.读取应用程序传送给设备文件的数据和回送应用程序请求的数据.
4.检测和处理设备出现的错误.
在Linux***作系统下有两类主要的设备文件类型,一种是字符设备,另一种是
块设备.字符设备和块设备的主要区别是:在对字符设备发出读/写请求时,实际
的硬件I/O一般就紧接着发生了,块设备则不然,它利用一块系统内存作缓冲区,
当用户进程对设备请求能满足用户的要求,就返回请求的数据,如果不能,就调用请求函数来进行实际
的I/O***作.块设备是主要针对磁盘等慢速设备设计的,以免耗费过多的CPU时间
来等待.
已经提到,用户进程是通过设备文件来与实际的硬件打交道.每个设备文件都
都有其文件属性(c/b),表示是字符设备还蔤强樯璞?另外每个文件都有两个设
备号,第一个是主设备号,标识驱动程序,第二个是从设备号,标识使用同一个
设备驱动程序的不同的硬件设备,比如有两个软盘,就可以用从设备号来区分
他们.设备文件的的主设备号必须与设备驱动程序在登记时申请的主设备号
一致,否则用户进程将无法访问到驱动程序.
最后必须提到的是,在用户进程调用驱动程序时,系统进入核心态,这时不再是
抢先式调度.也就是说,系统必须在你的驱动程序的子函数返回后才能进行其他
的工作.如果你的驱动程序陷入死循环,不幸的是你只有重新启动机器了,然后就
是漫长的fsck.//hehe
(请看下节,实例剖析)
读/写时,它首先察看缓冲区的内容,如果缓冲区的数据
如何编写Linux***作系统下的设备驱动程序
Roy G
二.实例剖析
我们来写一个最简单的字符设备驱动程序.虽然它什么也不做,但是通过它
可以了解Linux的设备驱动程序的工作原理.把下面的C代码输入机器,你就会
获得一个真正的设备驱动程序.不过我的kernel是2.0.34,在低版本的kernel
上可能会出现问题,我还没测试过.//xixi
#define __NO_VERSION__
#include
#include
char kernel_version [] = UTS_RELEASE;
这一段定义了一些版本信息,虽然用处不是很大,但也必不可少.Johnsonm说所
有的驱动程序的开头都要包含,但我看倒是未必.
由于用户进程是通过设备文件同硬件打交道,对设备文件的***作方式不外乎就
是一些系统调用,如 open,read,write,close...., 注意,不是fopen, fread.,
但是如何把系统调用和驱动程序关联起来呢?这需要了解一个非常关键的数据
结构:
struct file_operations {
int (*seek) (struct inode * ,struct file *, off_t ,int);
int (*read) (struct inode * ,struct file *, char ,int);
int (*write) (struct inode * ,struct file *, off_t ,int);
int (*readdir) (struct inode * ,struct file *, struct dirent * ,int);
int (*select) (struct inode * ,struct file *, int ,select_table *);
int (*ioctl) (struct inode * ,struct file *, unsined int ,unsigned long
int (*mmap) (struct inode * ,struct file *, struct vm_area_struct *);
int (*open) (struct inode * ,struct file *);
int (*release) (struct inode * ,struct file *);
int (*fsync) (struct inode * ,struct file *);
int (*fasync) (struct inode * ,struct file *,int);
int (*check_media_change) (struct inode * ,struct file *);
int (*revalidate) (dev_t dev);
}
这个结构的每一个成员的名字都对应着一个系统调用.用户进程利用系统调用
在对设备文件进行诸如read/write***作时,系统调用通过设备文件的主设备号
找到相应的设备驱动程序,然后读取这个数据结构相应的函数指针,接着把控制
权交给该函数.这是linux的设备驱动程序工作的基本原理.既然是这样,则编写
设备驱动程序的主要工作就是编写子函数,并填充file_operations的各个域.
相当简单,不是吗?
下面就开始写子程序.
#include
#include
#include
#include
#include
unsigned int test_major = 0;
static int read_test(struct inode *node,struct file *file,
char *buf,int count)
{
int left;
if (verify_area(VERIFY_WRITE,buf,count) == -EFAULT )
return -EFAULT;
for(left = count left > 0 left--)
{
__put_user(1,buf,1);
buf++;
}
return count;
}
这个函数是为read调用准备的.当调用read时,read_test()被调用,它把用户的
缓冲区全部写1.
buf 是read调用的一个参数.它是用户进程空间的一个地址.但是在read_test
被调用时,系统进入核心态.所以不能使用buf这个地址,必须用__put_user(),
这是kernel提供的一个函数,用于向用户传送数据.另外还有很多类似功能的
函数.请参考.在向用户空间拷贝数据之前,必须验证buf是否可用.
这就用到函数verify_area.
static int write_tibet(struct inode *inode,struct file *file,
const char *buf,int count)
{
return count;
}
static int open_tibet(struct inode *inode,struct file *file )
{
MOD_INC_USE_COUNT;
return 0;
} static void release_tibet(struct inode *inode,struct file *file )
{
MOD_DEC_USE_COUNT;
}
这几个函数都是空***作.实际调用发生时什么也不做，他们仅仅为下面的结构
提供函数指针。
struct file_operations test_fops = {
NULL,
read_test,
write_test,
NULL, /* test_readdir */
NULL,
NULL, /* test_ioctl */
NULL, /* test_mmap */
open_test,
release_test, NULL, /* test_fsync */
NULL, /* test_fasync */
/* nothing more, fill with NULLs */
};
设备驱动程序的主体可以说是写好了。现在要把驱动程序嵌入内核。驱动程序
可以按照两种方式编译。一种是编译进kernel，另一种是编译成模块(moles),
如果编译进内核的话，会增加内核的大小，还要改动内核的源文件，而且不能
动态的卸载，不利于调试，所以推荐使用模块方式。
int init_mole(void)
{
int result;
result = register_chrdev(0, "test", &test_fops);
if (result < 0) {
printk(KERN_INFO "test: can't get major number ");
return result;
}
if (test_major == 0) test_major = result; /* dynamic */
return 0;
}
在用insmod命令将编译好的模块调入内存时，init_mole 函数被调用。在
这里，init_mole只做了一件事，就是向系统的字符设备表登记了一个字符
设备。register_chrdev需要三个参数，参数一是希望获得的设备号，如果是
零的话，系统将选择一个没有被占用的设备号返回。参数二是设备文件名，
参数三用来登记驱动程序实际执行***作的函数的指针。
如果登记成功，返回设备的主设备号，不成功，返回一个负值。
void cleanup_mole(void)
{
unregister_chrdev(test_major, "test");
}
在用rmmod卸载模块时，cleanup_mole函数被调用，它释放字符设备test
在系统字符设备表中占有的表项。
一个极其简单的字符设备可以说写好了，文件名就叫test.c吧。
下面编译
$ gcc -O2 -DMODULE -D__KERNEL__ -c test.c
得到文件test.o就是一个设备驱动程序。
如果设备驱动程序有多个文件，把每个文件按上面的命令行编译，然后
ld -r file1.o file2.o -o molename.
驱动程序已经编译好了，现在把它安装到系统中去。
$ insmod -f test.o
如果安装成功，在/proc/devices文件中就可以看到设备test,
并可以看到它的主设备号,。
要卸载的话，运行
$ rmmod test
下一步要创建设备文件。
mknod /dev/test c major minor
c 是指字符设备，major是主设备号，就是在/proc/devices里看到的。
用shell命令
$ cat /proc/devices | awk "\$2=="test" {print \$1}"
就可以获得主设备号，可以把上面的命令行加入你的shell script中去。
minor是从设备号，设置成0就可以了。
我们现在可以通过设备文件来访问我们的驱动程序。写一个小小的测试程序。
#include
#include
#include
#include
main()
{
int testdev;
int i;
char buf[10];
testdev = open("/dev/test",O_RDWR);
if ( testdev == -1 )
{
printf("Cann't open file ");
exit(0);
}
read(testdev,buf,10);
for (i = 0; i < 10;i++)
printf("%d ",buf);
close(testdev);
}
编译运行，看看是不是打印出全1 ？
以上只是一个简单的演示。真正实用的驱动程序要复杂的多，要处理如中断，
DMA，I/O port等问题。这些才是真正的难点。请看下节，实际情况的处理。
如何编写Linux***作系统下的设备驱动程序
Roy G
三 设备驱动程序中的一些具体问题。
1. I/O Port.
和硬件打交道离不开I/O Port，老的ISA设备经常是占用实际的I/O端口，
在linux下，***作系统没有对I/O口屏蔽，也就是说，任何驱动程序都可以
对任意的I/O口***作，这样就很容易引起混乱。每个驱动程序应该自己避免
误用端口。
有两个重要的kernel函数可以保证驱动程序做到这一点。
1）check_region(int io_port, int off_set)
这个函数察看系统的I/O表，看是否有别的驱动程序占用某一段I/O口。
参数1：io端口的基地址，
参数2：io端口占用的范围。
返回值：0 没有占用， 非0，已经被占用。
2）request_region(int io_port, int off_set,char *devname)
如果这段I/O端口没有被占用，在我们的驱动程序中就可以使用它。在使用
之前，必须向系统登记，以防止被其他程序占用。登记后，在/proc/ioports
文件中可以看到你登记的io口。
参数1：io端口的基地址。
参数2：io端口占用的范围。
参数3：使用这段io地址的设备名。
在对I/O口登记后，就可以放心地用inb(), outb()之类的函来访问了。
在一些pci设备中，I/O端口被映射到一段内存中去，要访问这些端口就相当
于访问一段内存。经常性的，我们要获得一块内存的物理地址。在dos环境下，
（之所以不说是dos***作系统是因为我认为DOS根本就不是一个***作系统，它实
在是太简单，太不安全了）只要用段：偏移就可以了。在window95中，95ddk
提供了一个vmm 调用 _MapLinearToPhys,用以把线性地址转化为物理地址。但
在Linux中是怎样做的呢？
2 内存***作
在设备驱动程序中动态开辟内存，不是用malloc，而是kmalloc，或者用
get_free_pages直接申请页。释放内存用的是kfree，或free_pages. 请注意，
kmalloc等函数返回的是物理地址！而malloc等返回的是线性地址！关于
kmalloc返回的是物理地址这一点本人有点不太明白：既然从线性地址到物理
地址的转换是由386cpu硬件完成的，那样汇编指令的***作数应该是线性地址，
驱动程序同样也不能直接使用物理地址而是线性地址。但是事实上kmalloc
返回的确实是物理地址，而且也可以直接通过它访问实际的RAM，我想这样可
以由两种解释，一种是在核心态禁止分页，但是这好像不太现实；另一种是
linux的页目录和页表项设计得正好使得物理地址等同于线性地址。我的想法
不知对不对，还请高手指教。
言归正传，要注意kmalloc最大只能开辟128k-16，16个字节是被页描述符
结构占用了。kmalloc用法参见khg.
内存映射的I/O口，寄存器或者是硬件设备的RAM(如显存)一般占用F0000000
以上的地址空间。在驱动程序中不能直接访问，要通过kernel函数vremap获得
重新映射以后的地址。
另外，很多硬件需要一块比较大的连续内存用作DMA传送。这块内存需要一直
驻留在内存，不能被交换到文件中去。但是kmalloc最多只能开辟128k的内存。
这可以通过牺牲一些系统内存的方法来解决。
具体做法是：比如说你的机器由32M的内存，在lilo.conf的启动参数中加上
mem=30M，这样linux就认为你的机器只有30M的内存，剩下的2M内存在vremap
之后就可以为DMA所用了。
请记住，用vremap映射后的内存，不用时应用unremap释放，否则会浪费页表。
3 中断处理
同处理I/O端口一样，要使用一个中断，必须先向系统登记。
int request_irq(unsigned int irq ,
void(*handle)(int,void *,struct pt_regs *),
unsigned int long flags,
const char *device);
irq: 是要申请的中断。
handle：中断处理函数指针。
flags：SA_INTERRUPT 请求一个快速中断，0 正常中断。
device：设备名。
如果登记成功，返回0，这时在/proc/interrupts文件中可以看你请求的
中断。
4一些常见的问题。
对硬件***作，有时时序很重要。但是如果用C语言写一些低级的硬件***作
的话，gcc往往会对你的程序进行优化，这样时序就错掉了。如果用汇编写呢，
gcc同样会对汇编代码进行优化，除非你用volatile关键字修饰。最保险的
办法是禁止优化。这当然只能对一部分你自己编写的代码。如果对所有的代码
都不优化，你会发现驱动程序根本无法装载。这是因为在编译驱动程序时要
用到gcc的一些扩展特性，而这些扩展特性必须在加了优化选项之后才能体现
出来。
关于kernel的调试工具，我现在还没有发现有合适的。有谁知道请告诉我，
不胜感激。我一直都在printk打印调试信息，倒也还凑合。
关于设备驱动程序还有很多内容，如等待/唤醒机制，块设备的编写等。
我还不是很明白，不敢乱说。
4. Linux关于地址空间和MMAP映射有何特点
Linux采用
虚拟
内存技术，系统中的所有进程之间以虚拟方式共享内存。对每个进程来说，它们好像都可以访问整个系统的所有物理内存。更重要的是，即使单独一个进程，它拥有的地址空间也可以远远大于系统物理内存。
进程地址空间由每个进程中的线性地址区组成，每个进程都有一个32位或64位的平坦（flat）空间，空间的具体大小取决于体系结构。“平坦”指地址空间范围是一个独立的连续区间。通常情况下，每个进程都有唯一的这种平坦空间，而且每个进程的地址空间之间彼此互不相干。两个不同的进程可以在它们各自地址空间的相同地址内存存放不同的数据。但是进程之间也可以选择共享地址空间，我们称这样的进程为线程。
在地址空间中，我们更为关心的是进程有权访问的虚拟内存地址区间，比如08048000~0804c000。这些可被访问的合法地址区间被成为内存区域（memory area），通过内核，进程可以给自己的地址空间动态地添加或减少内存区域。
进程只能访问有效范围内的内存地址。每个内存区域也具有相应进程必须遵循的特定访问属性，如只读、只写、可执行等属性。如果一个进程访问了不在有效范围中的地址，或以不正确的方式访问有效地址，那么内核就会终止该进程，并返回“段错误”信息。
?
内存区域可以包含各种内存对象，如下：
?
可执行文件代码的内存映射，成为代码段（text section）。
?
可执行文件的已初始化全局变量的内存映射，成为数据段（data section）。
?
包含未初始化全局变量的零页（也就是bss段）的内存映射。零页是指页面中的数据全部为0。
?
用于进程用户空间栈的零页的内存映射。
?
每一个诸如C库或动态链接程序等共享库的代码段、数据段和bss也会被载入进程的地址空间。
?
任何内存映射文件。
?
任何共享内存段。
?
任何匿名的内存映射，比如由malloc（）分配的内存。
进程地址空间的任何有效地址都只能位于唯一的区域，这些内存区域不能相互覆盖。可以看到，在执行的进程中，每个不同的内存片断都对应一个独立的内存区域：栈、对象代码、全局变量、被映射的文件等等。
内核使用内存描述符表示进程的地址空间。内存描述符由mm_struct结构体表示，定义在文件中，该结构包含了和进程地址空间有关的全部信息。
VMA
内存区域由vm_area_struct结构体描述，定义在文件中，内存区域在内核中也经常被称作虚拟内存区域或者VMA。
VMA标志是一种位标志，它定义在vm_area_struct结构中（该结构中的vm_flags子域）。和物理页的访问权限不同，VMA标志反映了内核处理页面索需要遵守的行为准则，而不是硬件要求。VM_IO标志内存区域中包含对设备I/O空间的映射。该标志通常在设备驱动程序执行 mmap()函数进行I/O空间映射时才被设置，同时该标志也表示该内存区域不能被包含在任何进程的存放转存（core mp）中。VM_RESERVED标志内存区域不能被换出，它也是在设备驱动程序进行映射时被设置。
vm_area_struct结构体中的vm_ops域指向与指定内存区域相关的操作函数表，内核使用表中的方法操作VMA。
mmap()和do_mmap()：创建地址区间
内核使用do_mmap()函数创建一个新的线性地址区间。但是说给函数创建一个新VMA并不非常准确，因为如果创建的地址区间和一个已经存在的地址区间相邻，并且它们具有相同的访问权限的话，那么两个区间将合并为一个。如果不能合并，那么就确实需要创建一个新的VMA了。但无论哪种情况，do_mmap()函数都会将一个地址区间加入到进程的地址空间中——无论是扩展已经存在的内存区域还是创建一个新的区域。
do_mmap()函数声明在文件中，原型如下：
unsigned long do_mmap(struct file *file, unsigned long addr,
unsigned long len, unsigned long prot,
unsigned long flag, unsigned long offset)
在用户空间可以通过mmap()函数调用获取内核函数do_mmap()的功能。mmap()系统调用原型如下：
void *mmap2(void *start, size_t length,
int prot, int flags,
int fd, off_t pgoff)
do_munmap()函数从特定的进程地址空间中删除指定地址区间，该函数在文件中声明：
int do_munmap(struct mm_struct *mm, unsigned long start, size_t len)
系统调用munmap()给用户空间程序提供了一种从自身地址空间中删除指定地址区间的方法，它和系统调用mmap()的作用相反：
int munmap(void *start, size_t length)
mmap设备操作
对于驱动程序来说，内存映射可以提供给用户程序直接访问设备内存的能力。映射一个设备，意味着使用户空间的一段地址关联到设备内存上。无论何时，只要程序在分配的地址范围内进行读取或者写入，实际上就是对设备的访问。
并不是所有的设备都能进行mmap抽象。例如，串口设备和其他面向流的设备就无法实现这种抽象。mmap的另一个限制是映射都是以 PAGE_SIZE为单位的。内核只能在页表一级处理虚拟地址；因此，被映射的区域必须是PAGE_SIZE的整数倍，而且必须位于起始于 PAGE_SIZE整数倍地址的物理内存内。如果区域的大小不是页大小的整数倍，内核就通过生成一个稍微大一些的区域来容纳它。
mmap方法是file_operations结构中的一员，并且在执行mmap系统调用时就会调用该方法。在调用实际方法之前，内核会完成很多工作，而且该方法的原型与系统调用的原型由很大区别。关于Linux命令的介绍，看看《linux就该这么学》，具体关于这一章地址3w(dot)linuxprobe/chapter-02(dot)html
文件操作声明如下：
int (*mmap) (struct file * filp, struct vm_area_struct *vma);
其中vma参数包含了用于访问设备的虚拟地址区间的信息。大部分工作已经由内核完成了，要实现mmap，驱动程序只要为这一地址范围构造合适的页表即可，如果需要的话，就用一个新的操作集替换vma->vm_ops。
有两种建立页表的方法：使用remap_page_range函数可一次建立所有的页表，或者通过nopage VMA方法每次建立一个页表。
构造用于映射一段物理地址的新页表的工作是由remap_page_range完
5. 解释一下linux驱动程序结构框架及工作原理
一、Linux device driver 的概念
系统调用是操作系统内核和应用程序之间的接口，设备驱动程序是操作系统内核和机器硬件之间的接口。设备驱动程序为应用程序屏蔽了硬件的细节，这样在应用程序看来，硬件设备只是一个设备文件，应用程序可以象操作普通文件一样对硬件设备进行操作。设备驱动程序是内核的一部分，它完成以下的功能:
1、对设备初始化和释放；
2、把数据从内核传送到硬件和从硬件读取数据；
3、读取应用程序传送给设备文件的数据和回送应用程序请求的数据；
4、检测和处理设备出现的错误。
在Linux操作系统下有三类主要的设备文件类型，一是字符设备，二是块设备，三是网络设备。字符设备和块设备的主要区别是:在对字符设备发出读/写请求时，实际的硬件I/O一般就紧接着发生了，块设备则不然，它利用一块系统内存作缓冲区，当用户进程对设备请求能满足用户的要求，就返回请求的数据，如果不能，就调用请求函数来进行实际的I/O操作。块设备是主要针对磁盘等慢速设备设计的，以免耗费过多的CPU时间来等待。
已经提到，用户进程是通过设备文件来与实际的硬件打交道。每个设备文件都都有其文件属性(c/b)，表示是字符设备还是块设备?另外每个文件都有两个设备号，第一个是主设备号，标识驱动程序，第二个是从设备号，标识使用同一个设备驱动程序的不同的硬件设备，比如有两个软盘，就可以用从设备号来区分他们。设备文件的的主设备号必须与设备驱动程序在登记时申请的主设备号一致，否则用户进程将无法访问到驱动程序。
最后必须提到的是，在用户进程调用驱动程序时，系统进入核心态，这时不再是抢先式调度。也就是说，系统必须在你的驱动程序的子函数返回后才能进行其他的工作。如果你的驱动程序陷入死循环，不幸的是你只有重新启动机器了，然后就是漫长的fsck。
二、实例剖析
我们来写一个最简单的字符设备驱动程序。虽然它什么也不做，但是通过它可以了解Linux的设备驱动程序的工作原理。把下面的C代码输入机器，你就会获得一个真正的设备驱动程序。
由于用户进程是通过设备文件同硬件打交道，对设备文件的操作方式不外乎就是一些系统调用，如 open，read，write，close…， 注意，不是fopen， fread，但是如何把系统调用和驱动程序关联起来呢?这需要了解一个非常关键的数据结构：
STruct file_operatiONs {
int (*seek) (struct inode * ，struct file *， off_t ，int);
int (*read) (struct inode * ，struct file *， char ，int);
int (*write) (struct inode * ，struct file *， off_t ，int);
int (*readdir) (struct inode * ，struct file *， struct dirent * ，int);
int (*select) (struct inode * ，struct file *， int ，select_table *);
int (*ioctl) (struct inode * ，struct file *， unsined int ，unsigned long);
int (*mmap) (struct inode * ，struct file *， struct vm_area_struct *);
int (*open) (struct inode * ，struct file *);
int (*release) (struct inode * ，struct file *);
int (*fsync) (struct inode * ，struct file *);
int (*fasync) (struct inode * ，struct file *，int);
int (*check_media_change) (struct inode * ，struct file *);
int (*revalidate) (dev_t dev);
}
这个结构的每一个成员的名字都对应着一个系统调用。用户进程利用系统调用在对设备文件进行诸如read/write操作时，系统调用通过设备文件的主设备号找到相应的设备驱动程序，然后读取这个数据结构相应的函数指针，接着把控制权交给该函数。这是linux的设备驱动程序工作的基本原理。既然是这样，则编写设备驱动程序的主要工作就是编写子函数，并填充file_operations的各个域。
下面就开始写子程序。
#include <linux/types.h> 基本的类型定义
#include <linux/fs.h> 文件系统使用相关的头文件
#include <linux/mm.h>
#include <linux/errno.h>
#include <asm/segment.h>
unsigned int test_major = 0;
static int read_test(struct inode *inode，struct file *file，char *buf，int count)
{
int left; 用户空间和内核空间
if (verify_area(VERIFY_WRITE，buf，count) == -EFAULT )
return -EFAULT;
for(left = count ; left > 0 ; left--)
{
__put_user(1，buf，1);
buf++;
}
return count;
}
这个函数是为read调用准备的。当调用read时，read_test()被调用，它把用户的缓冲区全部写1。buf 是read调用的一个参数。它是用户进程空间的一个地址。但是在read_test被调用时，系统进入核心态。所以不能使用buf这个地址，必须用__put_user()，这是kernel提供的一个函数，用于向用户传送数据。另外还有很多类似功能的函数。请参考，在向用户空间拷贝数据之前，必须验证buf是否可用。这就用到函数verify_area。为了验证BUF是否可以用。
static int write_test(struct inode *inode，struct file *file，const char *buf，int count)
{
return count;
}
static int open_test(struct inode *inode，struct file *file )
{
MOD_INC_USE_COUNT; 模块计数加以，表示当前内核有个设备加载内核当中去
return 0;
}
static void release_test(struct inode *inode，struct file *file )
{
MOD_DEC_USE_COUNT;
}
这几个函数都是空操作。实际调用发生时什么也不做，他们仅仅为下面的结构提供函数指针。
struct file_operations test_fops = {?
read_test，
write_test，
open_test，
release_test，
};
设备驱动程序的主体可以说是写好了。现在要把驱动程序嵌入内核。驱动程序可以按照两种方式编译。一种是编译进kernel，另一种是编译成模块(moles)，如果编译进内核的话，会增加内核的大小，还要改动内核的源文件，而且不能动态的卸载，不利于调试，所以推荐使用模块方式。
int init_mole(void)
{
int result;
result = register_chrdev(0， "test"， &test_fops); 对设备操作的整个接口
if (result < 0) {
printk(KERN_INFO "test: can't get major number\n");
return result;
}
if (test_major == 0) test_major = result; /* dynamic */
return 0;
}
在用insmod命令将编译好的模块调入内存时，init_mole 函数被调用。在这里，init_mole只做了一件事，就是向系统的字符设备表登记了一个字符设备。register_chrdev需要三个参数，参数一是希望获得的设备号，如果是零的话，系统将选择一个没有被占用的设备号返回。参数二是设备文件名，参数三用来登记驱动程序实际执行操作的函数的指针。
如果登记成功，返回设备的主设备号，不成功，返回一个负值。
void cleanup_mole(void)
{
unregister_chrdev(test_major，"test");
}
在用rmmod卸载模块时，cleanup_mole函数被调用，它释放字符设备test在系统字符设备表中占有的表项。
一个极其简单的字符设备可以说写好了，文件名就叫test.c吧。
下面编译 :
$ gcc -O2 -DMODULE -D__KERNEL__ -c test.c –c表示输出制定名，自动生成.o文件
得到文件test.o就是一个设备驱动程序。
如果设备驱动程序有多个文件，把每个文件按上面的命令行编译，然后
ld ?-r ?file1.o ?file2.o ?-o ?molename。
驱动程序已经编译好了，现在把它安装到系统中去。
$ insmod ?–f ?test.o
如果安装成功，在/proc/devices文件中就可以看到设备test，并可以看到它的主设备号。要卸载的话，运行 :
$ rmmod test
下一步要创建设备文件。
mknod /dev/test c major minor
c 是指字符设备，major是主设备号，就是在/proc/devices里看到的。
用shell命令
$ cat /proc/devices
就可以获得主设备号，可以把上面的命令行加入你的shell script中去。
minor是从设备号，设置成0就可以了。
我们现在可以通过设备文件来访问我们的驱动程序。写一个小小的测试程序。
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
main()
{
int testdev;
int i;
char buf[10];
testdev = open("/dev/test"，O_RDWR);
if ( testdev == -1 )
{
printf("Cann't open file \n");
exit(0);
}
read(testdev，buf，10);
for (i = 0; i < 10;i++)
printf("%d\n"，buf[i]);
close(testdev);
}
编译运行，看看是不是打印出全1
以上只是一个简单的演示。真正实用的驱动程序要复杂的多，要处理如中断，DMA，I/O port等问题。这些才是真正的难点。上述给出了一个简单的字符设备驱动编写的框架和原理，更为复杂的编写需要去认真研究LINUX内核的运行机制和具体的设备运行的机制等等。希望大家好好掌握LINUX设备驱动程序编写的方法。