linux设备驱动归纳总结（八）：2.match.probe.remove

CU首页 ┊  fh265>> 博客  微博  相册  个人中心  好友  消息  [退出] ┊  随便看看

  博文

 博主

 相册

  投票

 活动

  发博文

公告：缅怀Dennis Ritchie活动开赛啦！

小白的博客——提升自已，分享别人

xiaobai.blog.chinaunix.net

好的女人可以不共享。好的技术绝对要共享！   

首页 |  博文目录 |  相册 |  博客圈 |  关于我 |  留言

个人资料

diytvgy

微博 论坛

发纸条 打招呼 加关注 加好友

• 博客访问：74427
• 博文数量：42
• 博客积分：687
• 博客等级：中校
• 关注人气： 4
• 注册时间：2010-12-01 18:55:26

文章分类

全部博文(42)

linux内核相关知识(1)

闲话(3)

linux内核与设备驱动(34)

ubuntu(2)

未分类博文(2)

订阅我的博客

• 
• 
• 
• 

好友

• 

  tekkama

• 

  小雅贝贝

• 

  luozhiy

• 

  Knivo

• 

  embedtek

• 

  sillybo

• 

  wang2kk

• 

  嵌入小凯

• 

  send_li

• 

  CU官方博

• 

  songtao

• 

  lxhhust

最近来访

• 

  fh265
  1小时前

• 

  shenhai
  10月30日

• 

  a275532
  10月14日

• 

  Knivo
  10月13日

• 

  
  10月13日

• 

  lxr215
  10月10日

• 

  luozhiy
  10月9日

• 

  chafe
  10月8日

• 

  mournju
  10月7日

• 

  zotozo
  10月7日

• 

  high_way
  10月7日

• 

  wangxin
  10月4日

字体大小：大 中 小博文

linux设备驱动归纳总结（八）：2.match.probe.remove (2011-02-02 23:13) 转载

标签:   linux   设备模型   总线   设备   驱动程序  分类：  8设备模型

linux设备驱动归纳总结（八）：2.总线、设备和驱动的关系

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

上一节介绍了总线、设备和驱动函数的注册，这节着重介绍它们三者的关系，和上一节一样，我模拟一条usb总线，一个usb鼠标设备和一个usb鼠标驱动函数，当然，只是名字是usb，里面并没有实质的操作，只是通过这样来介绍一下三者之间的关系。。

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

一、总线、设备和驱动函数在/sys/中的框架

首先要写三个函数，bus.c、device.c和driver.c。这几个函数其实就是上一节函数的精简版，去掉属性文件的创建，仅仅保留创建和注销操作。

第一个函数是bus.c，加载模块会创建了一条名叫usb的总线，总线目录放在/sys/bus/目录下：

/*8th_devModule_2/1st/bus.c*/

6 struct bus_type usb_bus = {

7 .name = "usb",         //注册成功后将在/sys/bus目录下看到目录usb

8 };

9

10 static int __init usb_bus_init(void)

11 {

12 int ret;

13 /*总线注册，必须检测返回值*/

14 ret = bus_register(&usb_bus);

15 if(ret){

16 printk("bus register failed!\n");

17 return ret;

18 }

19

20 printk("usb bus init\n");

21 return 0;

22 }

23

24 static void __exit usb_bus_exit(void)

25 {

26 bus_unregister(&usb_bus);

27 printk("usb bus bye!\n");

28 }

第二个函数是device.c，加载模块会创建目录/sys/device/usb_device来管理这个usb设备。

由于该设备指定了所属的总线是usb_bus，所有会在/sys/bus/usb/device目录下创建一了指向usb_device的软连接。

同时，在卸载模块时，usb_deivce被删除，内核自动调用release函数，现实当中release函数应该做一些卸载设备的相关操作，但是我的usb设备是我虚拟出来的，所以release函数只是打印了一句话。

/*8th_devModule_2/1st/device.c*/

5 extern struct bus_type usb_bus;

6

7 void usb_dev_release(struct device *dev) //卸载函数没有干具体的事情

8 {

9 printk("<kernel> release\n");

10 }

11

12 struct device usb_device = {

13 .bus_id = "usb_device",

14 .bus = &usb_bus,                   //指定该设备的总线,在/sys/bus/usb

15 .release = usb_dev_release, //必须要都有release函数，不然卸载时会出错

16 };

17

18 static int __init usb_device_init(void)

19 {

20 int ret;

21 /*设备注册，注册成功后在/sys/device目录下创建目录usb_device并在指定总线

22 * usb_bus的目录/sys/bus/usb/device创建/sys/device/usb_device的软连接*/

23 ret = device_register(&usb_device);

24 if(ret){

25 printk("device register failed!\n");

26 return ret;

27 }

28

29 printk("usb device init\n");

30 return 0;

31 }

32

33 static void __exit usb_device_exit(void)

34 {

35 device_unregister(&usb_device);

36 printk("usb device bye!\n");

37 }

第三个函数是driver.c，加载模块后会在指定的总线目录的driver目录，即/sys/bus/usb/driver目录下创建一个名叫usb_driver的目录来管理这个驱动函数。

/*8th_devModule_2/1st/driver.c*/

6 extern struct bus_type usb_bus;

7

8 struct device_driver usb_driver = {

9 .name = "usb_driver", //在/sys/中的驱动目录名字

10 .bus = &usb_bus,      //必须指定驱动函数所属总线，不然不能注册。

11 };

12

13 static int __init usb_driver_init(void)

14 {

15 int ret;

16 /*驱动注册，注册成功后在/sys/bus/usb/driver目录下创建目录usb_driver*/

17 ret = driver_register(&usb_driver);

18 if(ret){

19 printk("driver register failed!\n");

20 return ret;

21 }

22 printk("usb driver init\n");

23 return 0;

24 }

25

26 static void __exit usb_driver_exit(void)

27 {

28 driver_unregister(&usb_driver);

29 printk("usb driver bye!\n");

30 }

接下来看看效果，因为设备和驱动的都指定了所属总线，所以必须先加载总线的模块。同样的，在卸载总线的模块前，必须先把设备和驱动的模块先卸载。

[root: 1st]# insmod bus.ko //先加载bus.ko

usb bus init

[root: 1st]# ls /sys/bus/ //sys/bus目录下多了一个usb目录

platform scsi usb

[root: 1st]# insmod device.ko //再加载device.ko

usb device init

[root: 1st]# ls /sys/devices/ //sys/device目录下多了一个usb_device目录

platform system usb_device virtual

[root: 1st]# ls -l /sys/bus/usb/devices/ //同时将该目录软连接到指定的总线目录下

lrwxrwxrwx 1 root root 0 Oct 27 13:28 usb_device -> ../../../devices/usb_device

[root: 1st]# insmod driver.ko //加载driver.ko

usb driver init

[root: 1st]# ls /sys/bus/usb/drivers //在指定总线的driver目录下多了一个usb_driver目录

usb_driver //但它和设备的目录不一样，它并不是软连接。

[root: 1st]# lsmod //查看一下当前加载的模块

driver 1256 0 - Live 0xbf00c000

device 1560 0 - Live 0xbf006000

bus 1336 2 driver,device, Live 0xbf000000 //模块的引用计数，bus模块被device和driver引用

[root: 1st]# rmmod bus //如果你要卸载bus模块，它会提示出错，要先卸载driver和device

rmmod: remove 'bus': Resource temporarily unavailable

[root: 1st]# rmmod driver

usb driver bye!

[root: 1st]# rmmod device //卸载device时，内核自动调用device结构体中指定的release函数

<kernel> release

usb device bye!

[root: 1st]# lsmod //bus的引用计数为0，可以卸载bus了

bus 1336 0 - Live 0xbf012000

[root: 1st]# rmmod bus

usb bus bye!

最后来个图：

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

二、配对函数(match)、探测函数(probe)和卸载函数(remove)

现在讲一下三个函数：

第一个是配对函数(match)，它是总线结构体bus_type的其中一个成员：

57 int (*match)(struct device *dev, struct device_driver *drv);

当总线上添加了新设备或者新驱动函数的时候，内核会调用一次或者多次这个函数。

举例，如果我现在添加了一个新的驱动函数，内核就会调用所属总线的match函数，配对总线上所有的设备，如果驱动能够处理其中一个设备，函数返回0，告诉内核配对成功。

一般的，match函数是判断设备的结构体成员device->bus_id和驱动函数的结构体成员device_driver->name是否一致，如果一致，那就表明配对成功。

所以，bus.c修改如下，贴上修改的代码：

/*8th_devModule_2/2nd/bus.c*/

6 int usb_bus_match(struct device *dev, struct device_driver *drv)

7 {

8 if(!strcmp(dev->bus_id, drv->name)){

9 printk("match success\n"); //为了配对成功，设备的bus_id和驱动的name我都更改为

10 return 1;                             //usb_mouse，详细的可以查看device.c和driver.c

11 }else{

12 printk("match failed\n");

13 return 0;

14 }

15 }

16

17 struct bus_type usb_bus = {

18 .name = "usb",                    //注册成功后将在/sys/bus目录下看到目录usb

19 .match = usb_bus_match,

20 };

第二个是探测函数(probe)，它是驱动函数结构体中的一个成员：

129 int (*probe) (struct device *dev);

当配对(match)成功后，内核就会调用指定驱动中的probe函数来查询设备能否被该驱动操作，如果可以，驱动就会对该设备进行相应的操作，如初始化。所以说，真正的驱动函数入口是在probe函数中。

所以，driver.c修改如下：

/*8th_devModule_2/2nd/driver.c*/

8 void init_mouse(void)

9 {

10 printk("init usb mouse\n");

11 }

12

13 int usb_driver_probe(struct device *dev)

14 {//查询特定设备是否存在，以及是否能够才操作该设备，然后再进行设备操作。

15 //check_mouse(); //自己假设一下检查设备

16 init_mouse(); //usb鼠标驱动的真正入口

17 return 0;

18 }

。。。。。

26 struct device_driver usb_driver = {

27 .name = "usb_mouse", //在/sys/中的驱动目录名字，为了配对成功，修改为usb_mouse

28 .bus = &usb_bus, //必须指定驱动函数所属总线，不然不能注册。

29 .probe = usb_driver_probe,

30 。。。。。

31 };

第三个是卸载函数(remove)，它是驱动函数结构体中的一个成员：

130 int (*remove) (struct device *dev);

当该驱动函数或者驱动函数正在操作的设备被移除时，内核会调用驱动函数中的remove函数调用，进行一些设备卸载相应的操作。

所以，driver.c修改如下：

/*8th_devModule_2/2nd/driver.c*/

20 int usb_driver_remove(struct device *dev)

21 {

22 printk("remove mouse driver\n");

23 return 0;

24 }

25

26 struct device_driver usb_driver = {

27 .name = "usb_mouse", //在/sys/中的驱动目录名字

28 .bus = &usb_bus, //必须指定驱动函数所属总线，不然不能注册。

29 .probe = usb_driver_probe,

30 .remove = usb_driver_remove,

31 };

接下来就要验证一下了。当然，我的函数里面并没有真正的硬件操作，仅仅是打印出一句话：

[root: 2nd]# insmod bus.ko //必须先加载总线模块

usb bus init

[root: 2nd]# insmod device.ko

usb device init

[root: 2nd]# insmod driver.ko

match success //当加载了设备和驱动的模块后，内核调用总线的配对函数

match success //并且配对成功。

init usb mouse //配对成功后内核调用探测函数probe

usb driver init

[root: 2nd]# rmmod device

remove mouse driver //当设备卸载时，内核调用驱动函数中的remove

<kernel> release //同时也会调用设备中的release函数调用

usb device bye!

[root: 2nd]# rmmod driver

usb driver bye!

又到了举例时间，程序员最喜欢就是男女关系，那就以男女关系举例：

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

三、多个设备和驱动之间的配对

上面讲的内容都是一对一的配对，但是如果系统中有多个配对成功，内核会如何处理呢？

1、多个设备对应一个驱动：

下面要讲的情况是，如果多个设备与内核中的一个驱动函数配对成功时，内核会进行怎么样的操作，先看实例。

为了能够让多个设备配对成功，我将bus.c的配对条件修改了一下：

/*8th_devModule_2/3th/bus.c */

6 int usb_bus_match(struct device *dev, struct device_driver *drv)

7 { //仅仅配对名字的前9个字母是否相同

8 if(!strncmp(dev->bus_id, drv->name, 9)){

9 printk("match success\n");

10 return 1;

11 }else{

12 printk("match failed\n");

13 return 0;

14 }

15 }

同时在device.c的基础上拷贝了device1.c和device2.c，三个程序都差不多，可以自己看看。接下来直接看效果：

[root: /]# cd /review_driver/8th_devModule/8th_devModule_2/3th

[root: 3th]# insmod bus.ko //先加载总线

usb bus init

[root: 3th]# insmod driver.ko //再加载驱动

usb driver init

[root: 3th]# insmod device.ko //当加载device.ko时，配对成功

match success

init usb mouse //内核调用驱动中的probe

usb device init

[root: 3th]# insmod device1.ko //再加载device1.ko，也配对成功

match success

init usb mouse //内核有调用驱动中的probe

usb device1 init

[root: 3th]# insmod device2.ko //加载device2.ko，配对不成功

match failed

usb device2 init

上面的验证表明，一个驱动可以对应多个设备。在联想起我举得男人女人——一个男人可以配对多个女人，哈哈。

2、一个设备对应多个驱动

这个例子中我将driver.c拷贝多了一个driver1.c，两个程序基本相同，都能配对成功，但看看效果：

[root: 3th]# insmod bus.ko //先加载总线

usb bus init

[root: 3th]# insmod device.ko //再加载设备

usb device init

[root: 3th]# insmod driver.ko //加载driver.ko

match success //配对成功

match success

init usb mouse //并且调用了probe

usb driver init

[root: 3th]# insmod driver1.ko //再加载driver1.ko

match success //因为名字的前9个字母一样，所以也会配对成功

usb driver1 init //但不会调用probe，因为已经有一个驱动跟该设备配对了。

上面的验证表明，一个设备只能对应一个驱动。

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

四、总结

这节内容主要介绍了总线和驱动中的几个方法和总线、设备和驱动函数三者之间的关系。

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

源代码： 8th_devModule_2.rar   

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

写到现在，都差不多踏入新年了，不知道还有没有人在看博客，预祝一下新年快乐。总结还没写完，年前任务没完成。过年期间继续复习。

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

分享到： 新浪微博 QQ空间 开心网 豆瓣 人人网 twitter fb

0 
   顶

阅读(1343)┊  评论 (3)┊ 收藏(0)┊ 举报┊ 打印

前一篇： linux设备驱动归纳总结（八）：1.总线、设备和驱动

[发评论]  评论 重要提示：警惕虚假中奖信息!

• 
  回复  举报

  diytvgy  2011-08-23 19:53
  songtao0728: 二、配对函数(match)、探测函数(probe)和卸载函数(remove)方面测试出现问题:
  首先的的内核是2.6.32.2，仔细查找发现只有device结构体中的name变量换成了init_na.....

  这样的话。你直接把我三个代码中的device->name换成init_name就可以了。
• 
  回复  举报

  songtao0728  2011-08-22 15:20
  我试着改变match函数为
  int usb_bus_match(struct device *dev,struct device_driver *drv)
  {
  printk("dev->init_name=%s",dev->init_name);
  printk("drv->name=%s",drv->name);
  printk("match success!\n");
  return 1;
  }
  再次编译，下载到开发板，加载模块，成功，打印出来的内容为:
  dev->init_name=<NULL>drv->name=usb_mouseaamatch success!
  init usb mouse
  register usb_driver success!
  发现dev->init_name指针并没有指向我定义的名字，估计问题就出在这里~
  
  结下来我也查看了device结构体，感觉没有什么问题,麻烦再指点一下~~
• 
  回复  举报

  songtao0728  2011-08-22 15:12
  二、配对函数(match)、探测函数(probe)和卸载函数(remove)方面测试出现问题:
  首先的的内核是2.6.32.2，仔细查找发现只有device结构体中的name变量换成了init_name，其它均于楼主的内核一样
  int usb_bus_match(struct device *dev, struct device_driver *drv) 
  
  7 { 
  
  8 if(!strcmp(dev->bus_id, drv->name)){ 
  
  9 printk("match success\n"); //为了配对成功，设备的bus_id和驱动的name我都更改为
  
  10 return 1;                             //usb_mouse，详细的可以查看device.c和driver.c
  
  11 }else{ 
  
  12 printk("match failed\n"); 
  
  13 return 0; 
  
  14 } 
  注释掉的话，编译正常，下载开发板上后也正常。
  不注释掉的话，编译正常，但下载到开发板加载后出现OPPS，具体错误信息如下:
  Unable to handle kernel NULL pointer dereference at virtual address 00000000
  pgd = c3b68000
  [00000000] *pgd=33b04031, *pte=00000000, *ppte=00000000
  Internal error: Oops: 17 [#1]
  last sysfs file: /sys/devices/virtual/vc/vcs4/dev
  Modules linked in: driver(+) device bus [last unloaded: bus]
  CPU: 0    Not tainted  (2.6.32.2-FriendlyARM #2)
  PC is at strcmp+0x10/0x40
  LR is at usb_bus_match+0x18/0x48 [bus]
  pc : [<c014a610>]    lr : [<bf012018>]    psr: a0000013
  sp : c3b6fe50  ip : c3b6fe60  fp : c3b6fe5c
  r10: 00000000  r9 : c3b6e000  r8 : c0030088
  r7 : 00000000  r6 : c0181398  r5 : bf01e148  r4 : bf0180e0
  r3 : 00000000  r2 : 00000002  r1 : bf01e118  r0 : 00000000
  Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
  Control: c000717f  Table: 33b68000  DAC: 00000015
  Process insmod (pid: 754, stack limit = 0xc3b6e270)
  Stack: (0xc3b6fe50 to 0xc3b70000)
  fe40:                                     c3b6fe6c c3b6fe60 bf012018 c014a610
  fe60: c3b6fe8c c3b6fe70 c01813c4 bf012010 bf01e148 c3b6fe90 c0181398 00000000
  fe80: c3b6feb4 c3b6fe90 c0180aac c01813a8 c3b35cb8 c3b3af30 bf01e148 bf012118
  fea0: c3b3ab40 00000000 c3b6fec4 c3b6feb8 c0181124 c0180a4c c3b6fef4 c3b6fec8
  fec0: c0180304 c0181114 bf01e118 bf01e148 c04812a0 bf01e148 00000000 bf021000
  fee0: c0030088 00000000 c3b6ff14 c3b6fef8 c0181708 c0180270 c04812a0 c3b6e000
  ff00: 00000000 bf021000 c3b6ff2c c3b6ff18 bf02101c c0181698 c04812a0 c3b6e000
  ff20: c3b6ff7c c3b6ff30 c002f32c bf021010 00000000 00000000 00000000 00000000
  ff40: 00000000 000b8038 bf01e17c 00000000 00000d69 000b8038 bf01e17c 00000000
  ff60: 00000d69 c0030088 c3b6e000 00000000 c3b6ffa4 c3b6ff80 c006e394 c002f300
  ff80: c3b6ffa4 c3b6ff90 00000005 00000069 be99ee64 00000080 00000000 c3b6ffa8
  ffa0: c002fee0 c006e2d8 00000005 00000069 000b8038 00000d69 000a3cd0 00000000
  ffc0: 00000005 00000069 be99ee64 00000080 be99ee68 000a3cd0 be99ee68 00000000
  ffe0: 00000001 be99eb14 0001852c 401c8984 60000010 000b8038 00000000 00000000
  Backtrace:
  [<c014a600>] (strcmp+0x0/0x40) from [<bf012018>] (usb_bus_match+0x18/0x48 [bus])
  
  [<bf012000>] (usb_bus_match+0x0/0x48 [bus]) from [<c01813c4>] (__driver_attach+0
  x2c/0x98)
  [<c0181398>] (__driver_attach+0x0/0x98) from [<c0180aac>] (bus_for_each_dev+0x70
  /0x98)
  r7:00000000 r6:c0181398 r5:c3b6fe90 r4:bf01e148
  [<c0180a3c>] (bus_for_each_dev+0x0/0x98) from [<c0181124>] (driver_attach+0x20/0
  x28)
  r7:00000000 r6:c3b3ab40 r5:bf012118 r4:bf01e148
  [<c0181104>] (driver_attach+0x0/0x28) from [<c0180304>] (bus_add_driver+0xa4/0x2
  48)
  [<c0180260>] (bus_add_driver+0x0/0x248) from [<c0181708>] (driver_register+0x80/
  0x140)
  [<c0181688>] (driver_register+0x0/0x140) from [<bf02101c>] (mini2440_driver_init
  +0x1c/0x50 [driver])
  r7:bf021000 r6:00000000 r5:c3b6e000 r4:c04812a0
  [<bf021000>] (mini2440_driver_init+0x0/0x50 [driver]) from [<c002f32c>] (do_one_
  initcall+0x3c/0x1dc)
  r5:c3b6e000 r4:c04812a0
  [<c002f2f0>] (do_one_initcall+0x0/0x1dc) from [<c006e394>] (sys_init_module+0xcc
  /0x1fc)
  [<c006e2c8>] (sys_init_module+0x0/0x1fc) from [<c002fee0>] (ret_fast_syscall+0x0
  /0x28)
  r7:00000080 r6:be99ee64 r5:00000069 r4:00000005
  Code: e1a0c00d e92dd800 e24cb004 e3a03000 (e7d02003)
  ---[ end trace ea6a84bc322ef533 ]---
  Segmentation fault

发评论

验证码：     更换一张

关于我们 |  关于IT168 |  联系方式 |  广告合作 |  法律声明 |  免费注册

Copyright © 2001-2010 ChinaUnix.net All Rights Reserved 北京皓辰网域网络信息技术有限公司. 版权所有

感谢所有关心和支持过ChinaUnix的朋友们
京ICP证041476号 京ICP证060528号