前面我们分析了device、driver、bus三种类型，主要是三者的注册与注销，在sysfs中的目录与属性文件创建等内容。本节就来详细分析下，在设备注册到总线上时，总线是如何为其寻找对应的驱动的；在驱动注册到总线上时，总线又是如何为其寻找对应的设备的。

本节的实现代码集中在drivers/base/bus.c和drivers/base/dd.c中。

先来回忆下，在device_register()->device_add()中，先是调用bus_add_device()添加device与bus间的联系，并添加bus为device定义的属性，然后会调用bus_probe_device()。bus_probe_device()会试图为已挂在总线上的该设备寻找对应的驱动。我们的故事就从这里开始。

  1. /**
  2. * bus_probe_device - probe drivers for a new device
  3. * @dev: device to probe
  4. *
  5. * - Automatically probe for a driver if the bus allows it.
  6. */
  7. void bus_probe_device(struct device *dev)
  8. {
  9. struct bus_type *bus = dev->bus;
  10. int ret;
  11. if (bus && bus->p->drivers_autoprobe) {
  12. ret = device_attach(dev);
  13. WARN_ON(ret < 0);
  14. }
  15. }

bus_probe_device()为总线上的设备寻找驱动。它先是检查bus->p->drivers_autoprobe，看是否允许自动探测。允许了才会调用device_attach()进行实际的寻找工作。

说到bus->p->drivers_autoprobe这个变量，它是在bus_type_private中的，在调用bus_register()前都初始化不了，在bus_register()中自动定为1。所以，除非是用户空间通过drivers_autoprobe属性文件主动禁止，bus总是允许自动探测的，所有的bus都是如此。

  1. /**
  2. * device_attach - try to attach device to a driver.
  3. * @dev: device.
  4. *
  5. * Walk the list of drivers that the bus has and call
  6. * driver_probe_device() for each pair. If a compatible
  7. * pair is found, break out and return.
  8. *
  9. * Returns 1 if the device was bound to a driver;
  10. * 0 if no matching driver was found;
  11. * -ENODEV if the device is not registered.
  12. *
  13. * When called for a USB interface, @dev->parent->sem must be held.
  14. */
  15. int device_attach(struct device *dev)
  16. {
  17. int ret = 0;
  18. down(&dev->sem);
  19. if (dev->driver) {
  20. ret = device_bind_driver(dev);
  21. if (ret == 0)
  22. ret = 1;
  23. else {
  24. dev->driver = NULL;
  25. ret = 0;
  26. }
  27. } else {
  28. pm_runtime_get_noresume(dev);
  29. ret = bus_for_each_drv(dev->bus, NULL, dev, __device_attach);
  30. pm_runtime_put_sync(dev);
  31. }
  32. up(&dev->sem);
  33. return ret;
  34. }

device_attach()在实际绑定之前，会用dev->sem进行加锁。不错，dev->sem几乎就是为了在设备与驱动绑定或者解除绑定时加锁用的。还没有看到它在其它地方被调用。

如果在调用device_attach()前就已经有了dev->driver()，就调用device_bind_driver()进行绑定，不然还要调用bus_for_each_drv()进行依次匹配。至于pm_runtime_get_noresume之类的函数，属于电源管理部分，我们现在先忽略。

  1. static void driver_bound(struct device *dev)
  2. {
  3. if (klist_node_attached(&dev->p->knode_driver)) {
  4. printk(KERN_WARNING "%s: device %s already bound\n",
  5. __func__, kobject_name(&dev->kobj));
  6. return;
  7. }
  8. pr_debug("driver: '%s': %s: bound to device '%s'\n", dev_name(dev),
  9. __func__, dev->driver->name);
  10. if (dev->bus)
  11. blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
  12. BUS_NOTIFY_BOUND_DRIVER, dev);
  13. klist_add_tail(&dev->p->knode_driver, &dev->driver->p->klist_devices);
  14. }
  15. static int driver_sysfs_add(struct device *dev)
  16. {
  17. int ret;
  18. ret = sysfs_create_link(&dev->driver->p->kobj, &dev->kobj,
  19. kobject_name(&dev->kobj));
  20. if (ret == 0) {
  21. ret = sysfs_create_link(&dev->kobj, &dev->driver->p->kobj,
  22. "driver");
  23. if (ret)
  24. sysfs_remove_link(&dev->driver->p->kobj,
  25. kobject_name(&dev->kobj));
  26. }
  27. return ret;
  28. }
  29. static void driver_sysfs_remove(struct device *dev)
  30. {
  31. struct device_driver *drv = dev->driver;
  32. if (drv) {
  33. sysfs_remove_link(&drv->p->kobj, kobject_name(&dev->kobj));
  34. sysfs_remove_link(&dev->kobj, "driver");
  35. }
  36. }
  37. /**
  38. * device_bind_driver - bind a driver to one device.
  39. * @dev: device.
  40. *
  41. * Allow manual attachment of a driver to a device.
  42. * Caller must have already set @dev->driver.
  43. *
  44. * Note that this does not modify the bus reference count
  45. * nor take the bus's rwsem. Please verify those are accounted
  46. * for before calling this. (It is ok to call with no other effort
  47. * from a driver's probe() method.)
  48. *
  49. * This function must be called with @dev->sem held.
  50. */
  51. int device_bind_driver(struct device *dev)
  52. {
  53. int ret;
  54. ret = driver_sysfs_add(dev);
  55. if (!ret)
  56. driver_bound(dev);
  57. return ret;
  58. }

device_bind_driver()将device与driver绑定。它调用了两个内部函数。

其中drivers_sysfs_add()负责创建sysfs中driver和device指向对方的软链接。还有一个与它相对的函数drivers_sysfs_remove()。

driver_bound()则实际将device加入驱动的设备链表。

因为在调用device_bind_driver()之前就已经设置过dev->driver了，所以这样就将device和driver绑定了。

只是这样好像还缺少了什么，不错，之前看到driver时曾定义了drv->probe函数，bus->probe也有类似的功能，这里只是绑定，却没有调用probe函数。

让我们回过头来，继续看如果device_attach()中没有定义dev->driver会怎么样，是用bus_for_each_drv()对bus的驱动链表进行遍历，遍历函数使用__device_attach。

  1. static int __device_attach(struct device_driver *drv, void *data)
  2. {
  3. struct device *dev = data;
  4. if (!driver_match_device(drv, dev))
  5. return 0;
  6. return driver_probe_device(drv, dev);
  7. }

不要小看了__device_attach()，就是在__device_attach()中既完成了匹配工作，又完成了绑定工作。bus_for_each_drv()在遍历中，如果遍历函数返回值不为0，则遍历结束。所以在__device_attach()找到并绑定了适合的驱动，就会返回1停止遍历，否则继续遍历剩余的驱动。

先来看匹配工作，这是在driver_match_device()中完成的。

  1. static inline int driver_match_device(struct device_driver *drv,
  2. struct device *dev)
  3. {
  4. return drv->bus->match ? drv->bus->match(dev, drv) : 1;
  5. }

原来driver_match_device()实际是调用drv->bus->match()来完成设备和驱动的匹配的。其实这也是理所当然。因为总线不同，总线规范设备、厂商、类设备等定义的规格都不同，也只有bus亲自主持匹配工作。再具体的就只能等分析具体总线的时候了。

  1. int driver_probe_device(struct device_driver *drv, struct device *dev)
  2. {
  3. int ret = 0;
  4. if (!device_is_registered(dev))
  5. return -ENODEV;
  6. pr_debug("bus: '%s': %s: matched device %s with driver %s\n",
  7. drv->bus->name, __func__, dev_name(dev), drv->name);
  8. pm_runtime_get_noresume(dev);
  9. pm_runtime_barrier(dev);
  10. ret = really_probe(dev, drv);
  11. pm_runtime_put_sync(dev);
  12. return ret;
  13. }

如果driver_match_device()匹配成功了，__device_attach()就会继续调用driver_probe_devices()完成绑定。但driver_probe_devices()又是调用really_probe()完成的。

  1. static atomic_t probe_count = ATOMIC_INIT(0);
  2. static DECLARE_WAIT_QUEUE_HEAD(probe_waitqueue);
  3. static int really_probe(struct device *dev, struct device_driver *drv)
  4. {
  5. int ret = 0;
  6. atomic_inc(&probe_count);
  7. pr_debug("bus: '%s': %s: probing driver %s with device %s\n",
  8. drv->bus->name, __func__, drv->name, dev_name(dev));
  9. WARN_ON(!list_empty(&dev->devres_head));
  10. dev->driver = drv;
  11. if (driver_sysfs_add(dev)) {
  12. printk(KERN_ERR "%s: driver_sysfs_add(%s) failed\n",
  13. __func__, dev_name(dev));
  14. goto probe_failed;
  15. }
  16. if (dev->bus->probe) {
  17. ret = dev->bus->probe(dev);
  18. if (ret)
  19. goto probe_failed;
  20. } else if (drv->probe) {
  21. ret = drv->probe(dev);
  22. if (ret)
  23. goto probe_failed;
  24. }
  25. driver_bound(dev);
  26. ret = 1;
  27. pr_debug("bus: '%s': %s: bound device %s to driver %s\n",
  28. drv->bus->name, __func__, dev_name(dev), drv->name);
  29. goto done;
  30. probe_failed:
  31. devres_release_all(dev);
  32. driver_sysfs_remove(dev);
  33. dev->driver = NULL;
  34. if (ret != -ENODEV && ret != -ENXIO) {
  35. /* driver matched but the probe failed */
  36. printk(KERN_WARNING
  37. "%s: probe of %s failed with error %d\n",
  38. drv->name, dev_name(dev), ret);
  39. }
  40. /*
  41. * Ignore errors returned by ->probe so that the next driver can try
  42. * its luck.
  43. */
  44. ret = 0;
  45. done:
  46. atomic_dec(&probe_count);
  47. wake_up(&probe_waitqueue);
  48. return ret;
  49. }

really_probe()完成的绑定工作和device_bind_driver()差不多，只是它还会调用bus->probe或者drv->probe中定义的probe函数。

至于在really_probe()中使用probe_count保护，最后调用wake_up(&probe_waitqueue)，都是为了进行同步。

  1. /**
  2. * driver_probe_done
  3. * Determine if the probe sequence is finished or not.
  4. *
  5. * Should somehow figure out how to use a semaphore, not an atomic variable...
  6. */
  7. int driver_probe_done(void)
  8. {
  9. pr_debug("%s: probe_count = %d\n", __func__,
  10. atomic_read(&probe_count));
  11. if (atomic_read(&probe_count))
  12. return -EBUSY;
  13. return 0;
  14. }
  15. /**
  16. * wait_for_device_probe
  17. * Wait for device probing to be completed.
  18. */
  19. void wait_for_device_probe(void)
  20. {
  21. /* wait for the known devices to complete their probing */
  22. wait_event(probe_waitqueue, atomic_read(&probe_count) == 0);
  23. async_synchronize_full();
  24. }

driver_probe_done()检查当前是否有设备正在绑定驱动。

wait_for_device_probe()会阻塞到所有的设备绑定完驱动。

关于bus_probe_device()的过程就分析到这里，下面来看下bus_add_driver()又是怎样做的。

之前我们已经知道driver_register()把绝大部分操作都移到了bus_add_driver()中来。其中只有一点和设备与驱动的绑定相关，就是对driver_attach()的调用。

  1. int driver_attach(struct device_driver *drv)
  2. {
  3. return bus_for_each_dev(drv->bus, NULL, drv, __driver_attach);
  4. }

driver_attach()一如device_attach，只是这里是对总线的设备链表进行遍历，使用的遍历函数是__driver_attach()。

  1. static int __driver_attach(struct device *dev, void *data)
  2. {
  3. struct device_driver *drv = data;
  4. /*
  5. * Lock device and try to bind to it. We drop the error
  6. * here and always return 0, because we need to keep trying
  7. * to bind to devices and some drivers will return an error
  8. * simply if it didn't support the device.
  9. *
  10. * driver_probe_device() will spit a warning if there
  11. * is an error.
  12. */
  13. if (!driver_match_device(drv, dev))
  14. return 0;
  15. if (dev->parent) /* Needed for USB */
  16. down(&dev->parent->sem);
  17. down(&dev->sem);
  18. if (!dev->driver)
  19. driver_probe_device(drv, dev);
  20. up(&dev->sem);
  21. if (dev->parent)
  22. up(&dev->parent->sem);
  23. return 0;
  24. }

在__driver_attach()中，driver_match_device()就不说了，它是调到bus->match去的。

然后依然是加锁，调用driver_probe_device()函数。这就与__device_attach()的路径一致了。

不要以为就这样结束了，现在我们只是看到了把device和driver绑定到一起的方法，却没有看到解除绑定的方法。

既然绑定的方法是在设备和驱动注册的时候调用的，那解除绑定自然是在设备或驱动注销的时候。

还是先来看设备的，device_unregister()->device_del()会调用bus_remove_device()将设备从总线上删除。

bus_remove_device()是与bus_add_device()相对的，但也不仅如此，它还调用了device_release_driver()来解除与driver的绑定。

  1. /**
  2. * device_release_driver - manually detach device from driver.
  3. * @dev: device.
  4. *
  5. * Manually detach device from driver.
  6. * When called for a USB interface, @dev->parent->sem must be held.
  7. */
  8. void device_release_driver(struct device *dev)
  9. {
  10. /*
  11. * If anyone calls device_release_driver() recursively from
  12. * within their ->remove callback for the same device, they
  13. * will deadlock right here.
  14. */
  15. down(&dev->sem);
  16. __device_release_driver(dev);
  17. up(&dev->sem);
  18. }
  19. /*
  20. * __device_release_driver() must be called with @dev->sem held.
  21. * When called for a USB interface, @dev->parent->sem must be held as well.
  22. */
  23. static void __device_release_driver(struct device *dev)
  24. {
  25. struct device_driver *drv;
  26. drv = dev->driver;
  27. if (drv) {
  28. pm_runtime_get_noresume(dev);
  29. pm_runtime_barrier(dev);
  30. driver_sysfs_remove(dev);
  31. if (dev->bus)
  32. blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
  33. BUS_NOTIFY_UNBIND_DRIVER,
  34. dev);
  35. if (dev->bus && dev->bus->remove)
  36. dev->bus->remove(dev);
  37. else if (drv->remove)
  38. drv->remove(dev);
  39. devres_release_all(dev);
  40. dev->driver = NULL;
  41. klist_remove(&dev->p->knode_driver);
  42. if (dev->bus)
  43. blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
  44. BUS_NOTIFY_UNBOUND_DRIVER,
  45. dev);
  46. pm_runtime_put_sync(dev);
  47. }
  48. }

device_release_driver()还是负责加加锁，实际的工作由__device_release_driver()来完成。

除了sysfs和结构中解除绑定的操作，还调用了bus->remove或者driver->remove。

虽然device注销时与driver解除绑定很简单，但driver注销要与device解除绑定就要复杂一些，因为它要与设备链表上所有的设备解除绑定。

在driver_unregister()->bus_remove_driver()中，调用了driver_detach()函数。

  1. /**
  2. * driver_detach - detach driver from all devices it controls.
  3. * @drv: driver.
  4. */
  5. void driver_detach(struct device_driver *drv)
  6. {
  7. struct device_private *dev_prv;
  8. struct device *dev;
  9. for (;;) {
  10. spin_lock(&drv->p->klist_devices.k_lock);
  11. if (list_empty(&drv->p->klist_devices.k_list)) {
  12. spin_unlock(&drv->p->klist_devices.k_lock);
  13. break;
  14. }
  15. dev_prv = list_entry(drv->p->klist_devices.k_list.prev,
  16. struct device_private,
  17. knode_driver.n_node);
  18. dev = dev_prv->device;
  19. get_device(dev);
  20. spin_unlock(&drv->p->klist_devices.k_lock);
  21. if (dev->parent) /* Needed for USB */
  22. down(&dev->parent->sem);
  23. down(&dev->sem);
  24. if (dev->driver == drv)
  25. __device_release_driver(dev);
  26. up(&dev->sem);
  27. if (dev->parent)
  28. up(&dev->parent->sem);
  29. put_device(dev);
  30. }
  31. }

可以看到，driver_detach()基本操作就是与设备链表上的设备解除绑定。等了这么久，终于有个有点意思的地方。一看这个drv的设备链表遍历，首先明明是klist，却没使用标准的循环函数，奇怪，然后发现竟然没有将设备卸下链表的地方，更奇怪。其实再一想就明白了。你看到list_entry()中，是从设备链表末尾取设备解除绑定的，这是驱动生怕前面的设备解除绑定了，后面的就不工作了。也正是因为klist遍历是逆向的，所以无法使用标准函数。至于将设备卸下链表的地方，是在__device_release_driver()中。

或许会奇怪这里为什么会有get_device()和put_device()的操作。这是为了防止设备一取下链表，就会释放最后一个引用计数，导致直接注销。那时候的情况，一定是在占用了dev->sem的同时去等待dev->sem，通俗来说就是死锁。

通过driver_attach()和driver_detach()的训练，我们已经习惯在为设备加锁时，顺便为其父设备加锁。虽然在device_attach()和device_release_driver()中只是对设备本身加锁。或许是害怕在驱动与设备解除绑定的过程中，父设备突然也要解除绑定，导致不一致状态。为至于为什么设备方主动要求时不需要对父设备加锁，或许是设备的主动申请更靠谱，不会在子设备绑定或释放的同时，父设备也申请释放。总之，在linux看来，设备恐怕比驱动还要靠谱一些，从driver和bus的引用计数，从这里的加锁情况，都可以看出一二。

  1. void *dev_get_drvdata(const struct device *dev)
  2. {
  3. if (dev && dev->p)
  4. return dev->p->driver_data;
  5. return NULL;
  6. }
  7. void dev_set_drvdata(struct device *dev, void *data)
  8. {
  9. int error;
  10. if (!dev)
  11. return;
  12. if (!dev->p) {
  13. error = device_private_init(dev);
  14. if (error)
  15. return;
  16. }
  17. dev->p->driver_data = data;
  18. }

最后的dev_set_drvdata()是在dev->p->driver_data中存放驱动定义的数据。dev_get_drvdata()是获取这个数据。

不要 小看这个device_private结构中小小的driver_data，在驱动编写中总能派上大用场。当然也不是说没有driver_data就过不下去，毕竟驱动可以定义一个自己的device结构，并把通用的struct device内嵌其中，然后想放多少数据都行。可那样太麻烦，许多驱动都要专门设置这样一个变量，索性加到通用的数据结构中。而且是直接加到device_private中，眼不见为净，方便省事。

  1. /**
  2. * device_reprobe - remove driver for a device and probe for a new driver
  3. * @dev: the device to reprobe
  4. *
  5. * This function detaches the attached driver (if any) for the given
  6. * device and restarts the driver probing process.  It is intended
  7. * to use if probing criteria changed during a devices lifetime and
  8. * driver attachment should change accordingly.
  9. */
  10. int device_reprobe(struct device *dev)
  11. {
  12. if (dev->driver) {
  13. if (dev->parent)        /* Needed for USB */
  14. down(&dev->parent->sem);
  15. device_release_driver(dev);
  16. if (dev->parent)
  17. up(&dev->parent->sem);
  18. }
  19. return bus_rescan_devices_helper(dev, NULL);
  20. }

device_reprobe()显然是dev对之前的驱动不满意，要新绑定一个。

  1. static int __must_check bus_rescan_devices_helper(struct device *dev,
  2. void *data)
  3. {
  4. int ret = 0;
  5. if (!dev->driver) {
  6. if (dev->parent) /* Needed for USB */
  7. down(&dev->parent->sem);
  8. ret = device_attach(dev);
  9. if (dev->parent)
  10. up(&dev->parent->sem);
  11. }
  12. return ret < 0 ? ret : 0;
  13. }

bus_rescan_devices_helper()就是用来绑定新驱动的内部函数。

我们终于成功完成了对dd.c的分析，并将bus.c剩余的部分结了尾。想必大家已经充分领略了device、driver和bus的铁三角结构，下节我们将进入设备驱动模型的另一方天地。

Linux内核部件分析 设备驱动模型之device-driver相关推荐

  1. Linux内核部件分析 设备驱动模型之driver ---mark 详细

    Linux内核部件分析 设备驱动模型之driver 转载:https://www.linuxidc.com/Linux/2011-10/44627p7.htm 上节我们分析设备驱动模型中的device ...

  2. [转载]Linux内核大讲堂 (一) 设备驱动的基石驱动模型(1)

    [转载]Linux内核大讲堂 (一) 设备驱动的基石驱动模型(1) 2011年09月13日 可能把驱动模型放在第一章讲会会有点难度,但是只要能跨过这道坎,后面就会轻松很多,驱动模型是整个linux设备 ...

  3. linux内核部件分析之——设备驱动模型之class

    前面看过了设备驱动模型中的bus.device.driver,这三种都是有迹可循的.其中bus代表实际的总线,device代表实际的设备和接口,而driver则对应存在的驱动.但本节要介绍的class ...

  4. linux内核部件分析(十)——设备驱动模型之class,linux内核部件分析（十）——设备驱动模型之class...

    前面看过了设备驱动模型中的bus.device.driver,这三种都是有迹可循的.其中bus代表实际的总线,device代表实际的设备和接口,而driver则对应存在的驱动.但本节要介绍的class ...

  5. linux内核的块设备驱动框架详解

    1.块设备和字符设备的差异 (1)块设备只能以块为单位接受输入和返回输出,而字符设备则以字节为单位.大多数设备是字符设备,因为它们不需要缓冲而且不以固定块大小进行操作; (2)块设备对于 I/O 请求 ...

  6. Linux内核大讲堂之设备驱动的基石驱动模型(1)

    转自 http://blog.csdn.net/gqb_driver/article/details/8449588 转自:无为和尚的Linux内核大讲堂系列,并对个别地方进行了补充更正(见标红处). ...

  7. Linux内核大讲堂 (一) 设备驱动的基石驱动模型(1)

    可能把驱动模型放在第一章讲会会有点难度,但是只要能跨过这道坎,后面就会轻松很多,驱动模型是整个linux设备驱动的基石.大部分人把驱动模型叫做设备模型,但是我查了linux的帮助文档,就是在下载源码路 ...

  8. 【转】Linux内核大讲堂 (一) 设备驱动的基石驱动模型(1)

    原文传送门http://blog.csdn.net/z2007b/archive/2011/05/03/6388753.aspx 可能把驱动模型放在第一章讲会会有点难度,但是只要能跨过这道坎,后面就会 ...

  9. 设备驱动模型：device, bus, driver之间的联系

    对于驱动工程师而言,在移植porting对应设备的driver时,要在devicetree中增加对应的设备节点,其中有一个compatible属性,这个属性的字符串要和driver里面的of_devi ...

  10. linux设备驱动模型-linux驱动开发第5部分-朱有鹏-专题视频课程

    linux设备驱动模型-linux驱动开发第5部分-4285人已学习 课程介绍         本课程是linux驱动开发的第5个课程,主要内容是linux的设备驱动模型,包括总线.类.设备.驱动等概 ...

最新文章

  1. Eclipse配置注释模板
  2. mysql中的多行查询结果合并成一个
  3. 当前流行的J2EE WEB应用架构分析
  4. Thrown KeeperErrorCode = Unimplemented for /services exception
  5. Python3基础教程：元类详解
  6. php运行速度检测软件,PHP执行慢分析工具xdebug + webgrind
  7. 真正的创业是什么感觉？
  8. Halcon学习笔记——摄像机标定（1）
  9. 1 Spark机器学习 spark MLlib 入门
  10. prosody之component
  11. Oracle 创建用户授权视图，别名通过同义词解决
  12. BugkuCTF –备份是个好习惯
  13. 手机apk应用程序未安装解决办法
  14. ORACLE获取月初、月末日期
  15. 【C语言】求最小公倍数三种方法
  16. 优化爬山法之八皇后问题
  17. Jenkins+Bitbucket webhook 自动触发构建
  18. android应用前端,Android应用开发之浅谈移动前端适配
  19. SQL Server 容易忽略的错误
  20. HTML+CSS大作业HTML5期末大作业 旅游酒店网站设计——旅游酒店服务预订(1页) web网页设计—— 出游

热门文章

  1. poj 2406 Power Strings(KMP)
  2. Asp.Net水晶报表边框不显示之解决方法
  3. 研究发现，近一半生产容器存在漏洞
  4. 网站漏洞渗透检测过程与修复方案
  5. valgrind 报告 ecpg内存泄露 (二)
  6. JEECG支付服务窗平台与服务窗接口对接文档
  7. java中构造方法的执行过程
  8. 未能正确加载“Microsoft.VisualStudio.Editor.Implementation.EditorPackage”
  9. HTTP_X_FORWARDED_FOR 和 REMOTE_ADDR 的区别
  10. 【正则】正则表达式基础知识大全