网卡驱动注册到PCI过程(转)
来源:互联网 发布:汽车芯片编程器 编辑:程序博客网 时间:2024/05/18 02:32
1.1 简单介绍
Linux设备模型中三个很重要的概念就是总线、设备和驱动,即bus,device和driver。它们分别对应的数据结构分别为struct bus_type,struct device和struct device_driver。
总线是处理器与一个或多个设备之间的通道,在设备模型中,所有的设备都通过总线相连。在最底层,Linux系统中的每一个设备都用device结构的一个实例来表示。而驱动则是使总线上的设备能够完成它应该完成的功能。
在系统中有多种总线,如PCI总线、SCSI总线等。系统中的多个设备和驱动是通过总线让它们联系起来的。在bus_type中两个很重要的成员就是struct kset drivers和struct kset devices。它分别代表了连接在这个总线上的两个链,一个是设备链表,另一个则是设备驱动链表。也就是说,通过一个总线描述符,就可以找到挂载到这条总线上的设备,以及支持该总线的不同的设备驱动程序。
1.2 总线、设备与驱动的绑定
在系统启动时,它会对每种类型的总线创建一个描述符,并将使用该总线的设备链接到该总线描述符的devices链上来。也即是说在系统初始化时,它会扫描连接了哪些设备,并且为每个设备建立一个struce device变量,然后将该变量链接到这个设备所连接的总线的描述符上去。另一方面,每当加载了一个设备驱动,则系统也会准备一个struct device_driver结构的变量,然后再将这个变量也链接到它所在总线的描述符的drivers链上去。
对于设备来说,在结构体struct device中有两个重要的成员,一个是struct bus_type *bus,另一个是struct device_driver *driver。bus成员就表示该设备是链接到哪一个总线上的,而driver成员就表示当前设备是由哪个驱动程序所驱动的。对于驱动程序来说,在结构体struct device_driver中也有两个成员,struct bus_type *bus和struct list_head devices,这里的bus成员也是指向这个驱动是链接到哪个总线上的,而devices这个链表则是表示当前这个驱动程序可以去进行驱动的那些设备。一个驱动程序可以支持一个或多个设备,而一个设备则只会绑定给一个驱动程序。
对于device与device_driver之间建立联系的方式,主要有两种方式。第一种,在计算机启动的时候,总线开始扫描连接在其上的设备,为每个设备建立一个struct device变量并链接到该总线的devices链上,然后开始初始化不同的驱动程序,驱动程序到它所在的总线的devices链上去遍历每一个还没有被绑定给某个驱动的设备,然后再查看是否能够支持这种设备,如果它能够支持这种设备,则将这个设备与这个驱动联系起来。即,将这个设备的device变量加到驱动的devices链上,同时让struct device中的device_driver指向当前这个驱动。第二种则是热插拔。也即是在系统运行时插入了设备,此时内核会去查找在该bus链上注册了的device_driver,然后再将设备与驱动联系起来。设备与驱动根据什么规则联系起来,它们是如何被联系起来的代码我们将在后面的章节进行详细的描述。
1.3 PCI总线
PCI是一种在CPU与I/O设备之间进行高速数据传输的一种总线。有很多设备都是使用PCI总线的,网卡就是其中之一。我们在前面讲了那些总线、设备与驱动方面的知识,原因就在于网卡是连接到PCI总线上,所以PCI总线、网卡设备以及网卡驱动就成了我们研究网卡的一个很重要的线索,尤其是在网络的链路层部分。下图显示了在一个系统中PCI设备的一个框图:
PCI子系统声明了一个bus_type结构,为pci_bus_type。它就是PCI总线的描述符。在这个变量上,链接了PCI设备以及支持PCI设备的驱动程序。
1.4 PCI设备与驱动
PCI设备通常由一组参数唯一地标识,它们被vendorID,deviceID和class nodes所标识,即设备厂商,型号等,这些参数保存在pci_device_id结构中。每个PCI设备都会被分配一个pci_dev变量,内核就用这个数据结构来表示一个PCI设备。
所有的PCI驱动程序都必须定义一个pci_driver结构变量,在该变量中包含了这个PCI驱动程序所提供的不同功能的函数,同时,在这个结构中也包含了一个device_driver结构,这个结构定义了PCI子系统与PCI设备之间的接口。在注册PCI驱动程序时,这个结构将被初始化,同时这个pci_driver变量会被链接到pci_bus_type中的驱动链上去。
在pci_driver中有一个成员struct pci_device_id *id_table,它列出了这个设备驱动程序所能够处理的所有PCI设备的ID值。
1.5 PCI设备与驱动的绑定过程
下面描述一下对于PCI设备与驱动绑定的过程。首先在系统启动的时候,PCI总线会去扫描连接到这个总线上的设备,同时为每一个设备建立一个pci_dev结构,在这个结构中有一个device成员,并将这些pci_dev结构链接到PCI总线描述符上的devices链。如下图所示:
第二步是当PCI驱动被加载时,pci_driver结构体将被初始化,这一过程在函数pci_register_driver中:
drv->driver.bus = &pci_bus_type;
drv->driver.probe = pci_device_probe;
最后会调用driver_register(&drv->driver)将这个PCI驱动挂载到总线描述符的驱动链上。同时在注册的过程中,会根据pci_driver中的id_table中的ID值去查看该驱动支持哪些设备,将这些设备挂载到pci_driver中的devices链中来。如下图所示:
对于不同的设备,可能驱动程序也不一样,因此,对于上图中的Dev3,可能就需要另外一个驱动程序来对其进行驱动。所以当加载了Dev3的驱动程序时,其示意图如下图所示:
上面这三个示意图就描述了总线、设备以及驱动在系统中是如何进行相互联系的。前面对于驱动注册这些函数的描述较为简单,因为网卡是一个PCI设备,因此在后面具体地讲到网卡注册时再来详细地讲解和PCI相关的注册等函数。
1.6 小结
本部分主要讲解了总线、设备以及驱动方面的一些知识,由于网卡是一个PCI设备,因此具体地讲到了一点PCI总线、PCI设备及相应的PCI驱动方面的知识,但是由于PCI本身就是很大的一个子系统,因此这里不可能对其进行详细地讲解,在后面对网卡的分析中,将对网卡中涉及到的和PCI相关的部分进行讲解。
2. 网卡在PCI层的注册
2.1 数据结构
前面第一章讲了总线、设备以及驱动方面的关系,也讲到了大多数网卡设备实际上是一个PCI设备。因此,本章就讲解网卡设备在注册时是如何注册到PCI总线上去的。在这里,以Intel的E100网卡驱动进行讲解。
前面讲到每个PCI设备都由一组参数唯一地标识,这些参数保存在结构体pci_device_id中,如下所示:
每个PCI设备驱动都有一个pci_driver变量,它描述了一个PCI驱动的信息,如下所示:
每个PCI驱动中都有一个id_table成员变量,记录了当前这个驱动所能够进行驱动的那些设备的ID值。
对于E100网卡驱动来说,它的pci_driver变量定义为:
里面e100_id_table就表示该E100驱动所能够支持的PCI设备的ID号,其定义为:
当PCI层检测到一个PCI设备能够被某PCI驱动所支持时(这是通过函数pci_match_one_device来进行检测的),就会调用这个PCI驱动上的probe函数,在该函数中会对该特定的PCI设备进行一些具体的初始化等操作。比如对于E100设备驱动来说,其probe函数为e100_probe。在这个函数中,会对网卡设备进行初始化。
e100_probe主要就涉及到网卡设备net_device的初始化,我们现在先来关注一下从网卡注册一直到调用e100_probe这一个过程的整个流程。
2.2 E100初始化
E100驱动程序的初始化是在函数e100_init_module()中的,如下:
在这个函数中,调用了pci_register_driver()函数,对e100_driver这个驱动进行注册。
2.3 PCI注册
在前面我们已经看到,PCI的注册就是将PCI驱动程序挂载到其所在的总线的drivers链,同时扫描PCI设备,将它能够进行驱动的设备挂载到driver上的devices链表上来,这里,我们将详细地查看这整个流程的函数调用关系。
pci_register_driver()->__pci_register_driver()
即是将PCI设备中的driver变量的总线指向pci_bus_type这个总线描述符,同时设置驱动的名字等。
pci_bus_type定义如下:
然后再调用函数driver_register(&drv->driver);通过这个函数将这个PCI驱动中的struct device_driver driver成员变量注册到系统中去。
pci_register_driver()->__pci_register_driver()->driver_register()
driver_register()代码如下:
klist_init()是为设备驱动的klist_devices成员进行初始化,这个klist_devices是一个对链表进行操作的包裹结构,它会链接这个驱动能够支持的那些设备。
最后就调用bus_add_driver()函数。这个函数的功能就是将这个驱动加到其所在的总线的驱动链上。
pci_register_driver()->__pci_register_driver()->driver_register()->bus_add_driver()->driver_attach()
在bus_add_driver()函数中,最重要的是调用driver_attach()函数,其定义如下:
该函数遍历这个驱动所在的总线上的所有设备,然后将这些设备与当前驱动进行匹配,以检测这个驱动是否能够支持某个设备,也即是将设备与驱动联系起来。
bus_for_each_dev函数是扫描在drv->bus这个总线上的所有设备,然后将每个设备以及当前驱动这两个指针传递给__driver_attach函数。
pci_register_driver()->__pci_register_driver()->driver_register()->bus_add_driver()->driver_attach()->__driver_attach()
__driver_attach()函数是将驱动与设备联系起来的函数。
在函数中有两条语句:
也即是判断当前设备是否已经注册了一个驱动,如果没有注册驱动,则调用driver_probe_device()函数。
pci_register_driver()->__pci_register_driver()->driver_register()->bus_add_driver()->driver_attach()->__driver_attach()->driver_probe_device()
如下:
该函数首先会调用总线上的match函数,以判断当前的PCI驱动能否支持该PCI设备,如果可以,则继续往后面执行。
drv->bus->match函数也即是pci_bus_type中的match成员变量,它为pci_bus_match函数。
pci_register_driver()->__pci_register_driver()->driver_register()->bus_add_driver()->driver_attach()->__driver_attach()->driver_probe_device()->pci_bus_match()
pci_bus_match函数的作用就是将PCI设备与PCI驱动进行比较以检查该驱动是否能够支持这个设备。在函数的最前面是两个宏to_pci_dev和to_pci_driver。因为在函数执行的过程中,虽然最开始传进来的是pci_driver结构与pci_dev结构,但是在执行的时候却取了这两个结构体中的device_driver和device成员变量,所以现在就要通过这两个成员变量找到之前对应的pci_driver和pci_dev结构的地址。
#define to_pci_dev(n) container_of(n, struct pci_dev, dev)
#define to_pci_driver(drv) container_of(drv,struct pci_driver, driver)
这两个宏在<Linux Device Driver> 3rd书上有相应的讲解,这里也就是找到E100的pci_driver:e100_driver以及该网卡设备的pci_dev结构。现在就要对它们进行比较以看它们之间是否能够联系起来。这是通过函数pci_match_device实现的。
pci_register_driver()->__pci_register_driver()->driver_register()->bus_add_driver()->driver_attach()->__driver_attach()->driver_probe_device()->pci_bus_match()->pci_match_device()
pci_match_one_driver函数的作用是将一个PCI设备与PCI驱动进行比较,以查看它们是否相匹配。如果相匹配,则返回匹配的pci_device_id结构体指针。
此时,如果该PCI驱动已经找到了一个可以想符的PCI设备,则返回,然后再退回到之前的driver_probe_device函数中。在该函数最后将调用really_probe函数。将device_driver与device结构体指针作为参数传递到这个函数中。下面几行是调用驱动或者总线的probe函数来扫描设备。
pci_register_driver()->__pci_register_driver()->driver_register()->bus_add_driver()->driver_attach()->__driver_attach()->driver_probe_device()->really_probe()
在函数really_probe()中:
此时的dev->bus为pci_bus_type,其probe函数则对应为:pci_device_probe。
pci_register_driver()->__pci_register_driver()->driver_register()->bus_add_driver()->driver_attach()->__driver_attach()->driver_probe_device()->really_probe()->pci_device_probe()
同样,在该函数中会获得当前的PCI设备的pci_dev结构体指针以及PCI驱动程序的pci_driver结构体指针。分别使用宏to_pci_dev和to_pci_driver。最后则调用函数__pci_device_probe。在该函数中还会调用函数pci_call_probe,这是最后的函数
pci_register_driver()->__pci_register_driver()->driver_register()->bus_add_driver()->driver_attach()->__driver_attach()->driver_probe_device()->really_probe()->pci_device_probe()->__pci_device_probe()->pci_call_probe()
在函数pci_call_probe里有一条语句:
在此处就调用了pci_driver的probe函数,对于这里的E100驱动来说,它的probe函数是最开始注册的e100_probe函数,在该函数中会完成对网卡设备net_device的初始化等操作。
到这里,我们对网卡驱动的PCI层的初始化分析就告一个段落了,剩下的部分就是网卡驱动对网卡设备本身的初始化等操作。
2.4 函数调用流程图
在这里,为网卡在PCI层的注册画了一个函数调用的流程图,能够更直观地展现网卡从注册到调用其自身的网卡初始化的这一个函数调用过程。
86, ifconfig eth0 up 会导致 net_device->open被调用,内幕!
# strace ifconfig eth0 up 2>&1 |less -N
可以看到,它是先用sockfd = socket(AF_INET, SOCK_DGRAM, 0)生成一个sockfd文件描述符,
再ioctl(sockfd, SIOCSIFFLAGS, 加上IFF_UP标志)。 这样就导致了open方法的调用。
socket文件描述符都是用socket(2)系统调用生成的:
sys_socket() > sock_map_fd() > sock_attach_fd() :
dentry->d_op = &sockfs_dentry_operations;
...
init_file(file, sock_mnt, dentry, FMODE_READ|FMODE_WRITE, &socket_file_ops);
SOCK_INODE(sock)->i_fop = &socket_file_ops;
(回忆一下,这个是不是就类似于ext3_iget()里头对inode->i_fop的赋值?)
static const struct file_operations socket_file_ops = {
.owner = THIS_MODULE,
.llseek = no_llseek,
.aio_read = sock_aio_read,
.aio_write = sock_aio_write,
.poll = sock_poll,
.unlocked_ioctl = sock_ioctl,
#ifdef CONFIG_COMPAT
.compat_ioctl = compat_sock_ioctl,
#endif
.mmap = sock_mmap,
.open = sock_no_open, /* special open code to disallow open via /proc */
.release = sock_close,
.fasync = sock_fasync,
.sendpage = sock_sendpage,
.splice_write = generic_splice_sendpage,
.splice_read = sock_splice_read,
}
其unlocked_ioctl = sock_ioctl,那么我们沿着sock_ioctl走下去:
sock_ioctl() --switch到了default--> dev_ioctl() > --SIOCSIFFLAGS--> dev_ifsioc()
> dev_change_flags() :
if ((old_flags ^ flags) & IFF_UP) {IFF_UP/* Bit is different ? */
ret = ((old_flags & IFF_UP) ? dev_close : dev_open)(dev);
如果是设置了IFF_UP,就调用dev_open;如果是清除了IFF_UP,就调用dev_close。 看dev_open里的:
ret = dev->open(dev);
就在此时,struct net_device的open方法被调用。
当pci_dev消失时(设备被拔出),或者module被rmmod时。
pci_unregister_driver() > driver_unregister() > driver_detach() > __device_release_driver():
if (dev->bus && dev->bus->remove)
dev->bus->remove(dev);
else if (drv->remove)
drv->remove(dev);
对pci设备来说,这里的dev->bus就是&pci_bus_type,参考1)中的定义,我们知道其remove函数是
pci_device_remove():
struct pci_dev * pci_dev = to_pci_dev(dev);
struct pci_driver * drv = pci_dev->driver;
if (drv) {
if (drv->remove)
drv->remove(pci_dev);
pci_dev->driver = NULL;
}
增加/删除一个PCI device时的情景。
(只有boot时的enumeration和hotplug两种情况可能导致设备出现与消失)
pci device的发现:
[ pci_scan_slot() > pci_scan_single_device() > pci_scan_device()
> pci_device_add() ]
pci_bus_add_devices() > pci_bus_add_device() > device_add() > bus_attach_device() :
int device_attach(struct device *dev)
{
int ret = 0;
down(&dev->sem);
if (dev->driver) {
ret = device_bind_driver(dev);
if (ret == 0)
ret = 1;
else {
dev->driver = NULL;
ret = 0;
}
} else {
ret = bus_for_each_drv(dev->bus, NULL, dev, __device_attach);
}
up(&dev->sem);
return ret;
}
也就是说,如果已经有了dev->driver这个值,那么就直接bind上去;如果没有,那么:
bus_for_each_drv() > __device_attach() > driver_probe_device() > really_probe()
此后发生的情形就和从pci_register_driver()一直调用到really_probe()的一样了。
remove:
=======
pci_remove_bus_device() > pci_destroy_dev() > pci_stop_dev() > device_unregister() >
device_del() > bus_remove_device() > device_release_driver() > __device_release_driver() :
static void __device_release_driver(struct device *dev)
{
struct device_driver *drv;
drv = dev->driver;
if (drv) {
driver_sysfs_remove(dev);
sysfs_remove_link(&dev->kobj, "driver");
if (dev->bus)
blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
BUS_NOTIFY_UNBIND_DRIVER,
dev);
if (dev->bus && dev->bus->remove)
dev->bus->remove(dev);
else if (drv->remove)
drv->remove(dev);
devres_release_all(dev);
dev->driver = NULL;
klist_remove(&dev->knode_driver);
}
}
注意,如果可以,首先尝试调用pci_bus_type的remove方法(a.k.a pci_device_remove),否则调用
device_driver的remove方法。
- 网卡驱动注册到PCI过程(转)
- 【转】网卡驱动注册到PCI总线这一过程的分析
- 网卡驱动注册到PCI总线这一过程的分析
- 网卡驱动注册到PCI总线这一过程的分析 [复制链接]
- 网卡驱动注册到PCI总线这一过程的…
- 网卡驱动注册到PCI总线这一过程的…
- 网卡驱动注册到PCI总线这一过程的分析一
- 网卡驱动注册到PCI总线这一过程的分析二
- 网卡驱动注册到PCI总线这一过程的分析
- 网卡驱动注册到PCI总线这一过程的分析一
- 网卡驱动注册到PCI总线这一过程的分析二
- Linux PCI网卡驱动分析(转)
- linux pci网卡驱动
- PCI网卡驱动分析
- intel dpdk api pci设备驱动注册和初始化过程
- intel dpdk api pci设备驱动注册和初始化过程
- linux pci驱动(转)
- Linux PCI网卡驱动的详细分析
- redhat9.0 浏览器乱码问题
- 浅谈android移动开发之WebView(关于javascript与java对象之间的互调)
- 第14周任务1
- 大整数运算问题
- Windows内存管理与结构体MEMORY_BASIC_INFORMATION
- 网卡驱动注册到PCI过程(转)
- Win7配置驱动开发环境(wdk7.60)
- android中文api:Manifest.permission group
- Android 滑动效果入门篇(二)—— Gallery
- VirtualAlloc
- iPhone开发学习笔记007——Xcode4.2下iPhone多视图开发(自已创建MainWindow.xib和不用MainWindow.xib两种实现)
- Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1
- 用IDEA来开发Android
- halcon测量一个圆的直径