IO模型及select，poll，epoll和kqueue的区别
（一）首先，介绍几种常见的I/O模型及其区别，如下：
blocking I/O
nonblocking I/O
I/O multiplexing (select and poll)
signal driven I/O (SIGIO)
asynchronous I/O (the POSIX aio_functions)—————异步IO模型更大的特点是 完成后发回通知。
阻塞与否，取决于实现IO交换的方式。
异步阻塞是基于select，select函数本身的实现方式是阻塞的，而采用select函数有个好处就是它可以同时监听多个文件句柄.
异步非阻塞直接在完成后通知，用户进程只需要发起一个IO操作然后立即返回，等IO操作真正的完成以后，应用程序会得到IO操作完成的通知，此时用户进程只需要对数据进行处理就好了，不需要进行实际的IO读写操作，因为真正的IO读取或者写入操作已经由内核完成了。
1 blocking I/O
这个不用多解释吧，阻塞套接字。下图是它调用过程的图示：
重点解释下上图，下面例子都会讲到。首先application调用 recvfrom()转入kernel，注意kernel有2个过程，wait for data和copy data from kernel to user。直到最后copy complete后，recvfrom()才返回。此过程一直是阻塞的。
2 nonblocking I/O：
与blocking I/O对立的，非阻塞套接字，调用过程图如下：
可以看见，如果直接操作它，那就是个轮询。。直到内核缓冲区有数据。
3 I/O multiplexing (select and poll)
最常见的I/O复用模型，select。
select先阻塞，有活动套接字才返回。与blocking I/O相比，select会有两次系统调用，但是select能处理多个套接字。
4 signal driven I/O (SIGIO)
只有UNIX系统支持，感兴趣的课查阅相关资料
与I/O multiplexing (select and poll)相比，它的优势是，免去了select的阻塞与轮询，当有活跃套接字时，由注册的handler处理。
5 asynchronous I/O (the POSIX aio_functions)
很少有*nix系统支持，windows的IOCP则是此模型
完全异步的I/O复用机制，因为纵观上面其它四种模型，至少都会在由kernel copy data to appliction时阻塞。而该模型是当copy完成后才通知application，可见是纯异步的。好像只有windows的完成端口是这个模型，效率也很出色。
6 下面是以上五种模型的比较
可以看出，越往后，阻塞越少，理论上效率也是更优。
=====================分割线==================================
5种模型的比较比较清晰了，剩下的就是把select,epoll,iocp,kqueue按号入座那就OK了。
select和iocp分别对应第3种与第5种模型，那么epoll与kqueue呢？其实也于select属于同一种模型，只是更高级一些，可以看作有了第4种模型的某些特性，如callback机制。
为什么epoll,kqueue比select高级？
答案是，他们无轮询。因为他们用callback取代了。想想看，当套接字比较多的时候，每次select()都要通过遍历FD_SETSIZE个Socket来完成调度,不管哪个Socket是活跃的,都遍历一遍。这会浪费很多CPU时间。如果能给套接字注册某个回调函数，当他们活跃时，自动完成相关操作，那就避免了轮询，这正是epoll与kqueue做的。
windows or *nix （IOCP or kqueue/epoll）？
诚然，Windows的IOCP非常出色，目前很少有支持asynchronous I/O的系统，但是由于其系统本身的局限性，大型服务器还是在UNIX下。而且正如上面所述，kqueue/epoll 与 IOCP相比，就是多了一层从内核copy数据到应用层的阻塞，从而不能算作asynchronous I/O类。但是，这层小小的阻塞无足轻重，kqueue与epoll已经做得很优秀了。
提供一致的接口，IO Design Patterns
实际上，不管是哪种模型，都可以抽象一层出来，提供一致的接口，广为人知的有ACE,Libevent（基于reactor模式）这些，他们都是跨平台的，而且他们自动选择更优的I/O复用机制，用户只需调用接口即可。说到这里又得说说2个设计模式，Reactor and Proactor。见：Reactor模式--VS--Proactor模式。Libevent是Reactor模型，ACE提供Proactor模型。实际都是对各种I/O复用机制的封装。
Java nio包是什么I/O机制？
现在可以确定，目前的java本质是select()模型，可以检查/jre/bin/nio.dll得知。至于java服务器为什么效率还不错。。我也不得而知，可能是设计得比较好吧。。-_-。
=====================分割线==================================
总结一些重点：
只有IOCP是asynchronous I/O，其他机制或多或少都会有一点阻塞。
select低效是因为每次它都需要轮询。但低效也是相对的，视情况而定，也可通过良好的设计改善
epoll, kqueue、select是Reacor模式，IOCP是Proactor模式。
java nio包是select模型。。
（二）epoll 与select的区别
1. 使用多进程或者多线程，但是这种 *** 会造成程序的复杂，而且对与进程与线程的创建维护也需要很多的开销。（Apache服务器是用的子进程的方式，优点可以隔离用户） （同步阻塞IO）
2.一种较好的方式为I/O多路转接（I/O multiplexing）（貌似也翻译多路复用），先构造一张有关描述符的列表（epoll中为队列），然后调用一个函数，直到这些描述符中的一个准备好时才返回，返回时告诉进程哪些I/O就绪。select和epoll这两个机制都是多路I/O机制的解决方案，select为POSIX标准中的，而epoll为Linux所特有的。
区别（epoll相对select优点）主要有三：
1.select的句柄数目受限，在linux/posix_types.h头文件有这样的声明：#define __FD_SETSIZE 1024 表示select最多同时监听1024个fd。而epoll没有，它的限制是更大的打开文件句柄数目。
2.epoll的更大好处是不会随着FD的数目增长而降低效率，在selec中采用轮询处理，其中的数据结构类似一个数组的数据结构，而epoll是维护一个队列，直接看队列是不是空就可以了。epoll只会对"活跃"的socket进行操作---这是因为在内核实现中epoll是根据每个fd上面的callback函数实现的。那么，只有"活跃"的socket才会主动的去调用 callback函数（把这个句柄加入队列），其他idle状态句柄则不会，在这点上，epoll实现了一个"伪"AIO。但是如果绝大部分的I/O都是“活跃的”，每个I/O端口使用率很高的话，epoll效率不一定比select高（可能是要维护队列复杂）。
3.使用mmap加速内核与用户空间的消息传递。无论是select,poll还是epoll都需要内核把FD消息通知给用户空间，如何避免不必要的内存拷贝就很重要，在这点上，epoll是通过内核于用户空间mmap同一块内存实现的。
关于epoll工作模式ET，LT
epoll有两种工作方式
ET：Edge Triggered，边缘触发。仅当状态发生变化时才会通知，epoll_wait返回。换句话，就是对于一个事件，只通知一次。且只支持非阻塞的socket。
LT：Level Triggered，电平触发（默认工作方式）。类似select/poll,只要还有没有处理的事件就会一直通知，以LT方式调用epoll接口的时候，它就相当于一个速度比较快的poll.支持阻塞和不阻塞的socket。
三 Linux并发 *** 编程模型
1 Apache 模型，简称 PPC （ Process Per Connection ，）:为每个连接分配一个进程。主机分配给每个连接的时间和空间上代价较大，并且随着连接的增多，大量进程间切换开销也增长了。很难应对大量的客户并发连接。
2 TPC 模型（ Thread Per Connection ）：每个连接一个线程。和PCC类似。
3 select 模型：I/O多路复用技术。
.1 每个连接对应一个描述。select模型受限于 FD_SETSIZE即进程更大打开的描述符数linux2.6.35为1024,实际上linux每个进程所能打开描数字的个数仅受限于内存大小，然而在设计select的系统调用时，却是参考FD_SETSIZE的值。可通过重新编译内核更改此值，但不能根治此问题，对于百万级的用户连接请求 即便增加相应 进程数， 仍显得杯水车薪呀。
.2select每次都会扫描一个文件描述符的 *** ，这个 *** 的大小是作为select之一个参数传入的值。但是每个进程所能打开文件描述符若是增加了 ，扫描的效率也将减小。
.3内核到用户空间，采用内存复制传递文件描述上发生的信息。
4 poll 模型：I/O多路复用技术。poll模型将不会受限于FD_SETSIZE，因为内核所扫描的文件 描述符 *** 的大小是由用户指定的，即poll的第二个参数。但仍有扫描效率和内存拷贝问题。
5 pselect模型：I/O多路复用技术。同select。
6 epoll模型：
.1)无文件描述字大小限制仅与内存大小相关
.2)epoll返回时已经明确的知道哪个socket fd发生了什么事件，不用像select那样再一个个比对。
.3)内核到用户空间采用共享内存方式，传递消息。
四 ：FAQ
1、单个epoll并不能解决所有问题，特别是你的每个操作都比较费时的时候，因为epoll是串行处理的。 所以你有还是必要建立线程池来发挥更大的效能。
2、如果fd被注册到两个epoll中时，如果有时间发生则两个epoll都会触发事件。
3、如果注册到epoll中的fd被关闭，则其会自动被清除出epoll监听列表。
4、如果多个事件同时触发epoll，则多个事件会被联合在一起返回。
5、epoll_wait会一直监听epollhup事件发生，所以其不需要添加到events中。
6、为了避免大数据量io时，et模式下只处理一个fd,其他fd被饿死的情况发生。linux建议可以在fd联系到的结构中增加ready位，然后epoll_wait触发事件之后仅将其置位为ready模式，然后在下边轮询ready fd列表。
如何创建用于WindowsNT PCI 设备驱动程序
Linux下PCI设备驱动开发
1. 关键数据结构
PCI设备上有三种地址空间：PCI的I/O空间、PCI的存储空间和PCI的配置空间。CPU可以访问PCI设备上的所有地址空间，其中I/O空间和存储空间提供给设备驱动程序使用，而配置空间则由Linux内核中的PCI初始化代码使用。内核在启动时负责对所有PCI设备进行初始化，配置好所有的PCI设备，包括中断号以及I/O基址，并在文件/proc/pci中列出所有找到的PCI设备，以及这些设备的参数和属性。
Linux驱动程序通常使用结构（struct）来表示一种设备，而结构体中的变量则代表某一具体设备，该变量存放了与该设备相关的所有信息。好的驱动程序都应该能驱动多个同种设备，每个设备之间用次设备号进行区分，如果采用结构数据来代表所有能由该驱动程序驱动的设备，那么就可以简单地使用数组下标来表示次设备号。
在PCI驱动程序中，下面几个关键数据结构起着非常核心的作用：
pci_driver
这个数据结构在文件include/linux/pci.h里，这是Linux内核版本2.4之后为新型的PCI设备驱动程序所添加的，其中最主要的是用于识别设备的id_table结构，以及用于检测设备的函数probe( )和卸载设备的函数remove( )：
struct pci_driver {
struct list_head node;
char *name;
const struct pci_device_id *id_table;
int (*probe) (struct pci_dev *dev, const struct pci_device_id *id);
void (*remove) (struct pci_dev *dev);
int (*save_state) (struct pci_dev *dev, u32 state);
int (*suspend)(struct pci_dev *dev, u32 state);
int (*resume) (struct pci_dev *dev);
int (*enable_wake) (struct pci_dev *dev, u32 state, int enable);
};
pci_dev
这个数据结构也在文件include/linux/pci.h里，它详细描述了一个PCI设备几乎所有的
硬件信息，包括厂商ID、设备ID、各种资源等：
struct pci_dev {
struct list_head global_list;
struct list_head bus_list;
struct pci_bus *bus;
struct pci_bus *subordinate;
void *sysdata;
struct proc_dir_entry *procent;
unsigned int devfn;
unsigned short vendor;
unsigned short device;
unsigned short subsystem_vendor;
unsigned short subsystem_device;
unsigned int class;
u8 hdr_type;
u8 rom_base_reg;
struct pci_driver *driver;
void *driver_data;
u64 dma_mask;
u32 current_state;
unsigned short vendor_compatible[DEVICE_COUNT_COMPATIBLE];
unsigned short device_compatible[DEVICE_COUNT_COMPATIBLE];
unsigned int irq;
struct resource resource[DEVICE_COUNT_RESOURCE];
struct resource dma_resource[DEVICE_COUNT_DMA];
struct resource irq_resource[DEVICE_COUNT_IRQ];
char name[80];
char slot_name[8];
int active;
int ro;
unsigned short regs;
int (*prepare)(struct pci_dev *dev);
int (*activate)(struct pci_dev *dev);
int (*deactivate)(struct pci_dev *dev);
};
2. 基本框架
在用模块方式实现PCI设备驱动程序时，通常至少要实现以下几个部分：初始化设备模块、设备打开模块、数据读写和控制模块、中断处理模块、设备释放模块、设备卸载模块。下面给出一个典型的PCI设备驱动程序的基本框架，从中不难体会到这几个关键模块是如何组织起来的。
/* 指明该驱动程序适用于哪一些PCI设备 */
static struct pci_device_id demo_pci_tbl [] __initdata = {
{PCI_VENDOR_ID_DEMO, PCI_DEVICE_ID_DEMO,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, DEMO},
{0,}
};
/* 对特定PCI设备进行描述的数据结构 */
struct demo_card {
unsigned int magic;
/* 使用链表保存所有同类的PCI设备 */
struct demo_card *next;
/* ... */
}
/* 中断处理模块 */
static void demo_interrupt(int irq, void *dev_id, struct pt_regs *regs)
{
/* ... */
}
/* 设备文件操作接口 */
static struct file_operations demo_fops = {
owner: THIS_MODULE, /* demo_fops所属的设备模块 */
read: demo_read, /* 读设备操作*/
write: demo_write, /* 写设备操作*/
ioctl: demo_ioctl, /* 控制设备操作*/
mmap: demo_mmap, /* 内存重映射操作*/
open: demo_open, /* 打开设备操作*/
release: demo_release /* 释放设备操作*/
/* ... */
};
/* 设备模块信息 */
static struct pci_driver demo_pci_driver = {
name: demo_MODULE_NAME, /* 设备模块名称 */
id_table: demo_pci_tbl, /* 能够驱动的设备列表 */
probe: demo_probe, /* 查找并初始化设备 */
remove: demo_remove /* 卸载设备模块 */
/* ... */
};
static int __init demo_init_module (void)
{
/* ... */
}
static void __exit demo_cleanup_module (void)
{
pci_unregister_driver(demo_pci_driver);
}
/* 加载驱动程序模块入口 */
module_init(demo_init_module);
/* 卸载驱动程序模块入口 */
module_exit(demo_cleanup_module);
上面这段代码给出了一个典型的PCI设备驱动程序的框架，是一种相对固定的模式。需要注意的是，同加载和卸载模块相关的函数或数据结构都要在前面加上__init、__exit等标志符，以使同普通函数区分开来。构造出这样一个框架之后，接下去的工作就是如何完成框架内的各个功能模块了。
3. 初始化设备模块
在Linux系统下，想要完成对一个PCI设备的初始化，需要完成以下工作：
检查PCI总线是否被Linux内核支持；
检查设备是否插在总线插槽上，如果在的话则保存它所占用的插槽的位置等信息。
读出配置头中的信息提供给驱动程序使用。
当Linux内核启动并完成对所有PCI设备进行扫描、登录和分配资源等初始化操作的同时，会建立起系统中所有PCI设备的拓扑结构，此后当PCI驱动程序需要对设备进行初始化时，一般都会调用如下的代码：
static int __init demo_init_module (void)
{
/* 检查系统是否支持PCI总线 */
if (!pci_present())
return -ENODEV;
/* 注册硬件驱动程序 */
if (!pci_register_driver(demo_pci_driver)) {
pci_unregister_driver(demo_pci_driver);
return -ENODEV;
}
/* ... */
return 0;
}
驱动程序首先调用函数pci_present( )检查PCI总线是否已经被Linux内核支持，如果系统支持PCI总线结构，这个函数的返回值为0，如果驱动程序在调用这个函数时得到了一个非0的返回值，那么驱动程序就必须得中止自己的任务了。在2.4以前的内核中，需要手工调用pci_find_device( )函数来查找PCI设备，但在2.4以后更好的办法是调用pci_register_driver( )函数来注册PCI设备的驱动程序，此时需要提供一个pci_driver结构，在该结构中给出的probe探测例程将负责完成对硬件的检测工作。
static int __init demo_probe(struct pci_dev *pci_dev, const struct
pci_device_id *pci_id)
{
struct demo_card *card;
/* 启动PCI设备 */
if (pci_enable_device(pci_dev))
return -EIO;
/* 设备DMA标识 */
if (pci_set_dma_mask(pci_dev, DEMO_DMA_MASK)) {
return -ENODEV;
}
/* 在内核空间中动态申请内存 */
if ((card = kmalloc(sizeof(struct demo_card), GFP_KERNEL)) == NULL) {
printk(KERN_ERR "pci_demo: out of memory\n");
return -ENOMEM;
}
memset(card, 0, sizeof(*card));
/* 读取PCI配置信息 */
card-iobase = pci_resource_start (pci_dev, 1);
card-pci_dev = pci_dev;
card-pci_id = pci_id-device;
card-irq = pci_dev-irq;
card-next = devs;
card-magic = DEMO_CARD_MAGIC;
/* 设置成总线主DMA模式 */
pci_set_master(pci_dev);
/* 申请I/O资源 */
request_region(card-iobase, 64, card_names[pci_id-driver_data]);
return 0;
}
4. 打开设备模块
在这个模块里主要实现申请中断、检查读写模式以及申请对设备的控制权等。在申请控制权的时候，非阻塞方式遇忙返回，否则进程主动接受调度，进入睡眠状态，等待其它进程释放对设备的控制权。
static int demo_open(struct inode *inode, struct file *file)
{
/* 申请中断，注册中断处理程序 */
request_irq(card-irq, demo_interrupt, SA_SHIRQ,
card_names[pci_id-driver_data], card)) {
/* 检查读写模式 */
if(file-f_mode FMODE_READ) {
/* ... */
}
if(file-f_mode FMODE_WRITE) {
/* ... */
}
/* 申请对设备的控制权 */
down(card-open_sem);
while(card-open_mode file-f_mode) {
if (file-f_flags O_NONBLOCK) {
/* NONBLOCK模式，返回-EBUSY */
up(card-open_sem);
return -EBUSY;
} else {
/* 等待调度，获得控制权 */
card-open_mode |= f_mode (FMODE_READ | FMODE_WRITE);
up(card-open_sem);
/* 设备打开计数增1 */
MOD_INC_USE_COUNT;
/* ... */
}
}
}
5. 数据读写和控制信息模块
PCI设备驱动程序可以通过demo_fops 结构中的函数demo_ioctl( )，向应用程序提供对硬件进行控制的接口。例如，通过它可以从I/O寄存器里读取一个数据，并传送到用户空间里：
static int demo_ioctl(struct inode *inode, struct file *file, unsigned int
cmd, unsigned long arg)
{
/* ... */
switch(cmd) {
case DEMO_RDATA:
/* 从I/O端口读取4字节的数据 */
val = inl(card-iobae + 0x10);
/* 将读取的数据传输到用户空间 */
return 0;
}
/* ... */
}
事实上，在demo_fops里还可以实现诸如demo_read( )、demo_mmap( )等操作，Linux内核源码中的driver目录里提供了许多设备驱动程序的源代码，找那里可以找到类似的例子。在对资源的访问方式上，除了有I/O指令以外，还有对外设I/O内存的访问。对这些内存的操作一方面可以通过把I/O内存重新映射后作为普通内存进行操作，另一方面也可以通过总线主DMA（Bus Master DMA）的方式让设备把数据通过DMA传送到系统内存中。
6. 中断处理模块
PC的中断资源比较有限，只有0~15的中断号，因此大部分外部设备都是以共享的形式申请中断号的。当中断发生的时候，中断处理程序首先负责对中断进行识别，然后再做进一步的处理。
static void demo_interrupt(int irq, void *dev_id, struct pt_regs *regs)
{
struct demo_card *card = (struct demo_card *)dev_id;
u32 status;
spin_lock(card-lock);
/* 识别中断 */
status = inl(card-iobase + GLOB_STA);
if(!(status INT_MASK))
{
spin_unlock(card-lock);
return; /* not for us */
}
/* 告诉设备已经收到中断 */
outl(status INT_MASK, card-iobase + GLOB_STA);
spin_unlock(card-lock);
/* 其它进一步的处理，如更新DMA缓冲区指针等 */
}
7. 释放设备模块
释放设备模块主要负责释放对设备的控制权，释放占用的内存和中断等，所做的事情正好与打开设备模块相反：
static int demo_release(struct inode *inode, struct file *file)
{
/* ... */
/* 释放对设备的控制权 */
card-open_mode = (FMODE_READ | FMODE_WRITE);
/* 唤醒其它等待获取控制权的进程 */
wake_up(card-open_wait);
up(card-open_sem);
/* 释放中断 */
free_irq(card-irq, card);
/* 设备打开计数增1 */
MOD_DEC_USE_COUNT;
/* ... */
}
8. 卸载设备模块
卸载设备模块与初始化设备模块是相对应的，实现起来相对比较简单，主要是调用函数pci_unregister_driver( )从Linux内核中注销设备驱动程序：
static void __exit demo_cleanup_module (void)
{
pci_unregister_driver(demo_pci_driver);
}
小结
PCI总线不仅是目前应用广泛的计算机总线标准，而且是一种兼容性最强、功能最全的计算机总线。而Linux作为一种新的操作系统，其发展前景是无法估量的，同时也为PCI总线与各种新型设备互连成为可能。由于Linux源码开放，因此给连接到PCI总线上的任何设备编写驱动程序变得相对容易。本文介绍如何编译Linux下的PCI驱动程序，针对的内核版本是2.4。
select和epoll的区别
先说下本文框架，先是问题引出，然后概括两个机制的区别和联系，最后介绍每个接口的用法
一、问题引出 联系区别
问题的引出，当需要读两个以上的I/O的时候，如果使用阻塞式的I/O，那么可能长时间的阻塞在一个描述符上面，另外的描述符虽然有数据但是不能读出来，这样实时性不能满足要求，大概的解决方案有以下几种：
1.使用多进程或者多线程，但是这种 *** 会造成程序的复杂，而且对与进程与线程的创建维护也需要很多的开销。（Apache服务器是用的子进程的方式，优点可以隔离用户）
2.用一个进程，但是使用非阻塞的I/O读取数据，当一个I/O不可读的时候立刻返回，检查下一个是否可读，这种形式的循环为轮询（polling），这种 *** 比较浪费CPU时间，因为大多数时间是不可读，但是仍花费时间不断反复执行read系统调用。
3.异步I/O（asynchronous I/O），当一个描述符准备好的时候用一个信号告诉进程，但是由于信号个数有限，多个描述符时不适用。
4.一种较好的方式为I/O多路转接（I/O multiplexing）（貌似也翻译多路复用），先构造一张有关描述符的列表（epoll中为队列），然后调用一个函数，直到这些描述符中的一个准备好时才返回，返回时告诉进程哪些I/O就绪。select和epoll这两个机制都是多路I/O机制的解决方案，select为POSIX标准中的，而epoll为Linux所特有的。
区别（epoll相对select优点）主要有三：
1.select的句柄数目受限，在linux/posix_types.h头文件有这样的声明：#define __FD_SETSIZE 1024 表示select最多同时监听1024个fd。而epoll没有，它的限制是更大的打开文件句柄数目。
2.epoll的更大好处是不会随着FD的数目增长而降低效率，在selec中采用轮询处理，其中的数据结构类似一个数组的数据结构，而epoll是维护一个队列，直接看队列是不是空就可以了。epoll只会对"活跃"的socket进行操作---这是因为在内核实现中epoll是根据每个fd上面的callback函数实现的。那么，只有"活跃"的socket才会主动的去调用 callback函数（把这个句柄加入队列），其他idle状态句柄则不会，在这点上，epoll实现了一个"伪"AIO。但是如果绝大部分的I/O都是“活跃的”，每个I/O端口使用率很高的话，epoll效率不一定比select高（可能是要维护队列复杂）。
3.使用mmap加速内核与用户空间的消息传递。无论是select,poll还是epoll都需要内核把FD消息通知给用户空间，如何避免不必要的内存拷贝就很重要，在这点上，epoll是通过内核于用户空间mmap同一块内存实现的。
二、接口
1）select
1. int select(int maxfdp1, fd_set *restrict readfds, fd_set *restrict writefds, fd_set *restrict exceptfds, struct timeval *restrict tvptr);
struct timeval{
long tv_sec;
long tv_usec;
}
有三种情况：tvptr == NULL 永远等待；tvptr-tv_sec == 0 tvptr-tv_usec == 0 完全不等待；不等于0的时候为等待的时间。select的三个指针都可以为空，这时候select提供了一种比sleep更精确的定时器。注意select的之一个参数maxfdp1并不是描述符的个数，而是更大的描述符加1，一是起限 *** 用，防止出错，二来可以给内核轮询的时候提供一个上届，提高效率。select返回－1表示出错，0表示超时，返回正值是所有的已经准备好的描述符个数（同一个描述符如果读和写都准备好，对结果影响是+2）。
2.int FD_ISSET(int fd, fd_set *fdset); fd在描述符 *** 中非0，否则返回0
3.int FD_CLR(int fd, fd_set *fd_set); int FD_SET(int fd, fd_set *fdset) ;int FD_ZERO(fd_set *fdset);
用一段linux 中man里的话“FD_ZERO() clears a set.FD_SET() and FD_CLR() respectively add and remove a given file descriptor from a set. FD_ISSET() tests to see if a file descriptor is part of the set; this is useful after select() returns.”这几个函数与描述符的0和1没关系，只是添加删除检测描述符是否在set中。
2）epoll
1.int epoll_create(int size);
创建一个epoll的句柄，size用来告诉内核这个监听的数目一共有多大。这个参数不同于select()中的之一个参数，给出更大监听的fd+1的值。需要注意的是，当创建好epoll句柄后，它就是会占用一个fd值，在linux下如果查看/proc/进程id/fd/，是能够看到这个fd的，所以在使用完epoll后，必须调用close()关闭，否则可能导致fd被耗尽。
2. int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
epoll的事件注册函数，它不同与select()是在监听事件时告诉内核要监听什么类型的事件，而是在这里先注册要监听的事件类型。之一个参数是epoll_create()的返回值，第二个参数表示动作，用三个宏来表示：
EPOLL_CTL_ADD：注册新的fd到epfd中；
EPOLL_CTL_MOD：修改已经注册的fd的监听事件；
EPOLL_CTL_DEL：从epfd中删除一个fd；
第三个参数是需要监听的fd，第四个参数是告诉内核需要监听什么事，struct epoll_event结构如下：
struct epoll_event {
__uint32_t events; /* Epoll events */
epoll_data_t data; /* User data variable */
};
events可以是以下几个宏的 *** ：
EPOLLIN ：表示对应的文件描述符可以读（包括对端SOCKET正常关闭）；
EPOLLOUT：表示对应的文件描述符可以写；
EPOLLPRI：表示对应的文件描述符有紧急的数据可读（这里应该表示有带外数据到来）；
EPOLLERR：表示对应的文件描述符发生错误；
EPOLLHUP：表示对应的文件描述符被挂断；
EPOLLET： 将EPOLL设为边缘触发(Edge Triggered)模式，这是相对于水平触发(Level Triggered)来说的。
EPOLLONESHOT：只监听一次事件，当监听完这次事件之后，如果还需要继续监听这个socket的话，需要再次把这个socket加入到EPOLL队列里
关于epoll工作模式ET，LT
LT(level triggered)是缺省的工作方式，并且同时支持block和no-block socket.在这种做法中，内核告诉你一个文件描述符是否就绪了，然后你可以对这个就绪的fd进行IO操作。如果你不作任何操作，内核还是会继续通知你的，所以，这种模式编程出错误可能性要小一点。传统的select/poll都是这种模型的代表．
ET (edge-triggered)是高速工作方式，只支持no-block socket。在这种模式下，当描述符从未就绪变为就绪时，内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知，直到你做了某些操作导致那个文件描述符不再为就绪状态了，但是请注意，如果一直不对这个fd作IO操作(从而导致它再次变成未就绪)，内核不会发送更多的通知(only once)
3. int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout)
等待事件的产生，类似于select()调用。参数events用来从内核得到事件的 *** ，maxevents告之内核这个events有多大，这个maxevents的值不能大于创建epoll_create()时的size，参数timeout是超时时间（毫秒，0会立即返回，-1永久阻塞）。该函数返回需要处理的事件数目，如返回0表示已超时。
三、参考：
APUE(I/O多路转接)
linux man epoll select
什么是嵌入式系统？怎么样学好它？
嵌入式系统（Embedded System ），IEEE对于嵌入式系统的定义是：An Embedded system is the devices used to control, monitor, or assist the operation of equipment, machinery or plants.嵌入式系统是“用于控制、监视或者辅助操作机器和设备的装置”。
在中国嵌入式系统领域，比较认同的嵌入式系统概念是：嵌入式系统是以应用为中心，以计算机技术为基础，并且软硬件可裁剪，适用于应用系统对功能、可靠性、成本、体积、功耗有严格要求的专用计算机系统。它一般由嵌入式微处理器、外围硬件设备、嵌入式操作系统以及用户的应用程序等四个部分组成，用于实现对其他设备的控制、监视或管理等功能。
嵌入式系统一般指非PC系统，它包括硬件和软件两部分。硬件包括处理器／微处理器、存储器及外设器件和I／O端口、图形控制器等。软件部分包括操作系统软件（OS）（要求实时和多任务操作）和应用程序编程。有时设计人员把这两种软件组合在一起。应用程序控制着系统的运作和行为；而操作系统控制着应用程序编程与硬件的交互作用。
嵌入式系统的核心是嵌入式微处理器。嵌入式微处理器一般就具备以下4个特点：
1）对实时多任务有很强的支持能力，能完成多任务并且有较短的中断响应时间，从而使内部的代码和实时内核心的执行时间减少到更低限度。
2）具有功能很强的存储区保护功能。这是由于嵌入式系统的软件结构已模块化，而为了避免在软件模块之间出现错误的交叉作用，需要设计强大的存储区保护功能，同时也有利于软件诊断。
3）可扩展的处理器结构，以能最迅速地开展出满足应用的更高性能的嵌入式微处理器。
4）嵌入式微处理器必须功耗很低，尤其是用于便携式的无线及移动的计算和通信设备中靠电池供电的嵌入式系统更是如此，如需要功耗只有mW甚至μW级。
嵌入式计算机系统同通用型计算机系统相比具有以下特点：
1.嵌入式系统通常是面向特定应用的嵌入式CPU与通用型的更大不同就是嵌入式CPU大多工作在为特定用户群设计的系统中，它通常都具有低功耗、体积小、集成度高等特点，能够把通用CPU中许多由板卡完成的任务集成在芯片内部，从而有利于嵌入式系统设计趋于小型化，移动能力大大增强，跟 *** 的耦合也越来越紧密。
2.嵌入式系统是将先进的计算机技术、半导体技术和电子技术与各个行业的具体应用相结合后的产物。这一点就决定了它必然是一个技术密集、资金密集、高度分散、不断创新的知识集成系统。
3.嵌入式系统的硬件和软件都必须高效率地设计，量体裁衣、去除冗余，力争在同样的硅片面积上实现更高的性能，这样才能在具体应用中对处理器的选择更具有竞争力。
4.嵌入式系统和具体应用有机地结合在一起，它的升级换代也是和具体产品同步进行，因此嵌入式系统产品一旦进入市场，具有较长的生命周期。
5.为了提高执行速度和系统可靠性，嵌入式系统中的软件一般都固化在存储器芯片或单片机本身中，而不是存贮于磁盘等载体中。
6.嵌入式系统本身不具备自举开发能力，即使设计完成以后用户通常也是不能对其中的程序功能进行修改的，必须有一套开发工具和环境才能进行开发。
7.目前，嵌入式系统多用于手机等操作系统的开发。具有巨大的市场潜力.
只要用心就能学好
如何写linux pci设备驱动程序
Linux下PCI设备驱动开发
1. 关键数据结构
PCI设备上有三种地址空间：PCI的I/O空间、PCI的存储空间和PCI的配置空间。CPU可以访问PCI设备上的所有地址空间，其中I/O空间和存储空间提供给设备驱动程序使用，而配置空间则由Linux内核中的PCI初始化代码使用。内核在启动时负责对所有PCI设备进行初始化，配置好所有的PCI设备，包括中断号以及I/O基址，并在文件/proc/pci中列出所有找到的PCI设备，以及这些设备的参数和属性。
Linux驱动程序通常使用结构（struct）来表示一种设备，而结构体中的变量则代表某一具体设备，该变量存放了与该设备相关的所有信息。好的驱动程序都应该能驱动多个同种设备，每个设备之间用次设备号进行区分，如果采用结构数据来代表所有能由该驱动程序驱动的设备，那么就可以简单地使用数组下标来表示次设备号。
在PCI驱动程序中，下面几个关键数据结构起着非常核心的作用：
pci_driver
这个数据结构在文件include/linux/pci.h里，这是Linux内核版本2.4之后为新型的PCI设备驱动程序所添加的，其中最主要的是用于识别设备的id_table结构，以及用于检测设备的函数probe( )和卸载设备的函数remove( )：
struct pci_driver {
struct list_head node;
char *name;
const struct pci_device_id *id_table;
int (*probe) (struct pci_dev *dev, const struct pci_device_id *id);
void (*remove) (struct pci_dev *dev);
int (*save_state) (struct pci_dev *dev, u32 state);
int (*suspend)(struct pci_dev *dev, u32 state);
int (*resume) (struct pci_dev *dev);
int (*enable_wake) (struct pci_dev *dev, u32 state, int enable);
};
pci_dev
这个数据结构也在文件include/linux/pci.h里，它详细描述了一个PCI设备几乎所有的
硬件信息，包括厂商ID、设备ID、各种资源等：
struct pci_dev {
struct list_head global_list;
struct list_head bus_list;
struct pci_bus *bus;
struct pci_bus *subordinate;
void *sysdata;
struct proc_dir_entry *procent;
unsigned int devfn;
unsigned short vendor;
unsigned short device;
unsigned short subsystem_vendor;
unsigned short subsystem_device;
unsigned int class;
u8 hdr_type;
u8 rom_base_reg;
struct pci_driver *driver;
void *driver_data;
u64 dma_mask;
u32 current_state;
unsigned short vendor_compatible[DEVICE_COUNT_COMPATIBLE];
unsigned short device_compatible[DEVICE_COUNT_COMPATIBLE];
unsigned int irq;
struct resource resource[DEVICE_COUNT_RESOURCE];
struct resource dma_resource[DEVICE_COUNT_DMA];
struct resource irq_resource[DEVICE_COUNT_IRQ];
char name[80];
char slot_name[8];
int active;
int ro;
unsigned short regs;
int (*prepare)(struct pci_dev *dev);
int (*activate)(struct pci_dev *dev);
int (*deactivate)(struct pci_dev *dev);
};
2. 基本框架
在用模块方式实现PCI设备驱动程序时，通常至少要实现以下几个部分：初始化设备模块、设备打开模块、数据读写和控制模块、中断处理模块、设备释放模块、设备卸载模块。下面给出一个典型的PCI设备驱动程序的基本框架，从中不难体会到这几个关键模块是如何组织起来的。
/* 指明该驱动程序适用于哪一些PCI设备 */
static struct pci_device_id demo_pci_tbl [] __initdata = {
{PCI_VENDOR_ID_DEMO, PCI_DEVICE_ID_DEMO,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, DEMO},
{0,}
};
/* 对特定PCI设备进行描述的数据结构 */
struct demo_card {
unsigned int magic;
/* 使用链表保存所有同类的PCI设备 */
struct demo_card *next;
/* ... */
}
/* 中断处理模块 */
static void demo_interrupt(int irq, void *dev_id, struct pt_regs *regs)
{
/* ... */
}
/* 设备文件操作接口 */
static struct file_operations demo_fops = {
owner: THIS_MODULE, /* demo_fops所属的设备模块 */
read: demo_read, /* 读设备操作*/
write: demo_write, /* 写设备操作*/
ioctl: demo_ioctl, /* 控制设备操作*/
mmap: demo_mmap, /* 内存重映射操作*/
open: demo_open, /* 打开设备操作*/
release: demo_release /* 释放设备操作*/
/* ... */
};
/* 设备模块信息 */
static struct pci_driver demo_pci_driver = {
name: demo_MODULE_NAME, /* 设备模块名称 */
id_table: demo_pci_tbl, /* 能够驱动的设备列表 */
probe: demo_probe, /* 查找并初始化设备 */
remove: demo_remove /* 卸载设备模块 */
/* ... */
};
static int __init demo_init_module (void)
{
/* ... */
}
static void __exit demo_cleanup_module (void)
{
pci_unregister_driver(demo_pci_driver);
}
/* 加载驱动程序模块入口 */
module_init(demo_init_module);
/* 卸载驱动程序模块入口 */
module_exit(demo_cleanup_module);
上面这段代码给出了一个典型的PCI设备驱动程序的框架，是一种相对固定的模式。需要注意的是，同加载和卸载模块相关的函数或数据结构都要在前面加上__init、__exit等标志符，以使同普通函数区分开来。构造出这样一个框架之后，接下去的工作就是如何完成框架内的各个功能模块了。
3. 初始化设备模块
在Linux系统下，想要完成对一个PCI设备的初始化，需要完成以下工作：
检查PCI总线是否被Linux内核支持；
检查设备是否插在总线插槽上，如果在的话则保存它所占用的插槽的位置等信息。
读出配置头中的信息提供给驱动程序使用。
当Linux内核启动并完成对所有PCI设备进行扫描、登录和分配资源等初始化操作的同时，会建立起系统中所有PCI设备的拓扑结构，此后当PCI驱动程序需要对设备进行初始化时，一般都会调用如下的代码：
static int __init demo_init_module (void)
{
/* 检查系统是否支持PCI总线 */
if (!pci_present())
return -ENODEV;
/* 注册硬件驱动程序 */
if (!pci_register_driver(demo_pci_driver)) {
pci_unregister_driver(demo_pci_driver);
return -ENODEV;
}
/* ... */
return 0;
}
驱动程序首先调用函数pci_present( )检查PCI总线是否已经被Linux内核支持，如果系统支持PCI总线结构，这个函数的返回值为0，如果驱动程序在调用这个函数时得到了一个非0的返回值，那么驱动程序就必须得中止自己的任务了。在2.4以前的内核中，需要手工调用pci_find_device( )函数来查找PCI设备，但在2.4以后更好的办法是调用pci_register_driver( )函数来注册PCI设备的驱动程序，此时需要提供一个pci_driver结构，在该结构中给出的probe探测例程将负责完成对硬件的检测工作。
static int __init demo_probe(struct pci_dev *pci_dev, const struct
pci_device_id *pci_id)
{
struct demo_card *card;
/* 启动PCI设备 */
if (pci_enable_device(pci_dev))
return -EIO;
/* 设备DMA标识 */
if (pci_set_dma_mask(pci_dev, DEMO_DMA_MASK)) {
return -ENODEV;
}
/* 在内核空间中动态申请内存 */
if ((card = kmalloc(sizeof(struct demo_card), GFP_KERNEL)) == NULL) {
printk(KERN_ERR "pci_demo: out of memory\n");
return -ENOMEM;
}
memset(card, 0, sizeof(*card));
/* 读取PCI配置信息 */
card-iobase = pci_resource_start (pci_dev, 1);
card-pci_dev = pci_dev;
card-pci_id = pci_id-device;
card-irq = pci_dev-irq;
card-next = devs;
card-magic = DEMO_CARD_MAGIC;
/* 设置成总线主DMA模式 */
pci_set_master(pci_dev);
/* 申请I/O资源 */
request_region(card-iobase, 64, card_names[pci_id-driver_data]);
return 0;
}
4. 打开设备模块
在这个模块里主要实现申请中断、检查读写模式以及申请对设备的控制权等。在申请控制权的时候，非阻塞方式遇忙返回，否则进程主动接受调度，进入睡眠状态，等待其它进程释放对设备的控制权。
static int demo_open(struct inode *inode, struct file *file)
{
/* 申请中断，注册中断处理程序 */
request_irq(card-irq, demo_interrupt, SA_SHIRQ,
card_names[pci_id-driver_data], card)) {
/* 检查读写模式 */
if(file-f_mode FMODE_READ) {
/* ... */
}
if(file-f_mode FMODE_WRITE) {
/* ... */
}
/* 申请对设备的控制权 */
down(card-open_sem);
while(card-open_mode file-f_mode) {
if (file-f_flags O_NONBLOCK) {
/* NONBLOCK模式，返回-EBUSY */
up(card-open_sem);
return -EBUSY;
} else {
/* 等待调度，获得控制权 */
card-open_mode |= f_mode (FMODE_READ | FMODE_WRITE);
up(card-open_sem);
/* 设备打开计数增1 */
MOD_INC_USE_COUNT;
/* ... */
}
}
}
5. 数据读写和控制信息模块
PCI设备驱动程序可以通过demo_fops 结构中的函数demo_ioctl( )，向应用程序提供对硬件进行控制的接口。例如，通过它可以从I/O寄存器里读取一个数据，并传送到用户空间里：
static int demo_ioctl(struct inode *inode, struct file *file, unsigned int
cmd, unsigned long arg)
{
/* ... */
switch(cmd) {
case DEMO_RDATA:
/* 从I/O端口读取4字节的数据 */
val = inl(card-iobae + 0x10);
/* 将读取的数据传输到用户空间 */
return 0;
}
/* ... */
}
事实上，在demo_fops里还可以实现诸如demo_read( )、demo_mmap( )等操作，Linux内核源码中的driver目录里提供了许多设备驱动程序的源代码，找那里可以找到类似的例子。在对资源的访问方式上，除了有I/O指令以外，还有对外设I/O内存的访问。对这些内存的操作一方面可以通过把I/O内存重新映射后作为普通内存进行操作，另一方面也可以通过总线主DMA（Bus Master DMA）的方式让设备把数据通过DMA传送到系统内存中。
6. 中断处理模块
PC的中断资源比较有限，只有0~15的中断号，因此大部分外部设备都是以共享的形式申请中断号的。当中断发生的时候，中断处理程序首先负责对中断进行识别，然后再做进一步的处理。
static void demo_interrupt(int irq, void *dev_id, struct pt_regs *regs)
{
struct demo_card *card = (struct demo_card *)dev_id;
u32 status;
spin_lock(card-lock);
/* 识别中断 */
status = inl(card-iobase + GLOB_STA);
if(!(status INT_MASK))
{
spin_unlock(card-lock);
return; /* not for us */
}
/* 告诉设备已经收到中断 */
outl(status INT_MASK, card-iobase + GLOB_STA);
spin_unlock(card-lock);
/* 其它进一步的处理，如更新DMA缓冲区指针等 */
}
7. 释放设备模块
释放设备模块主要负责释放对设备的控制权，释放占用的内存和中断等，所做的事情正好与打开设备模块相反：
static int demo_release(struct inode *inode, struct file *file)
{
/* ... */
/* 释放对设备的控制权 */
card-open_mode = (FMODE_READ | FMODE_WRITE);
/* 唤醒其它等待获取控制权的进程 */
wake_up(card-open_wait);
up(card-open_sem);
/* 释放中断 */
free_irq(card-irq, card);
/* 设备打开计数增1 */
MOD_DEC_USE_COUNT;
/* ... */
}
8. 卸载设备模块
卸载设备模块与初始化设备模块是相对应的，实现起来相对比较简单，主要是调用函数pci_unregister_driver( )从Linux内核中注销设备驱动程序：
static void __exit demo_cleanup_module (void)
{
pci_unregister_driver(demo_pci_driver);
}
小结
PCI总线不仅是目前应用广泛的计算机总线标准，而且是一种兼容性最强、功能最全的计算机总线。而Linux作为一种新的操作系统，其发展前景是无法估量的，同时也为PCI总线与各种新型设备互连成为可能。由于Linux源码开放，因此给连接到PCI总线上的任何设备编写驱动程序变得相对容易。本文介绍如何编译Linux下的PCI驱动程序，针对的内核版本是2.4。
0条大神的评论