前面我们分析了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()会试图为已挂在总线上的该设备寻找对应的驱动。我们的故事就从这里开始。
[cpp]view plaincopyprint?
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.
12.if (bus && bus->p->drivers_autoprobe) {
13. ret = device_attach(dev);
14. WARN_ON(ret < 0);
15. }
16.}
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都是如此。[cpp]view plaincopyprint?
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.
19. down(&dev->sem);
20.if (dev->driver) {
21. ret = device_bind_driver(dev);
22.if (ret == 0)
23. ret = 1;
24.else {
25. dev->driver = NULL;
26. ret = 0;
27. }
28. } else {
29. pm_runtime_get_noresume(dev);
30. ret = bus_for_each_drv(dev->bus, NULL, dev, __device_attach);
31. pm_runtime_put_sync(dev);
32. }
33. up(&dev->sem);
34.return ret;
35.}
device_attach()在实际绑定之前，会用dev->sem进行加锁。不错，dev->sem几乎就是为了在设备与驱动绑定或者解除绑定时加锁用的。还没有看到它在其它地方被调用。
如果在调用device_attach()前就已经有了dev->driver()，就调用device_bind_driver()进行绑定，不然还要调用bus_for_each_drv()进行依次匹配。至于pm_runtime_get_noresume 之类的函数，属于电源管理部分，我们现在先忽略。
[cpp]view plaincopyprint?
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.
9. pr_debug("driver: '%s': %s: bound to device '%s'\n", dev_name(dev),
10. __func__, dev->driver->name);
11.
12.if (dev->bus)
13. blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
14. BUS_NOTIFY_BOUND_DRIVER, dev);
15.
16. klist_add_tail(&dev->p->knode_driver, &dev->driver->p->klist_devices);
17.}
18.
19.static int driver_sysfs_add(struct device *dev)
20.{
21.int ret;
22.
23. ret = sysfs_create_link(&dev->driver->p->kobj, &dev->kobj,
24. kobject_name(&dev->kobj));
25.if (ret == 0) {
26. ret = sysfs_create_link(&dev->kobj, &dev->driver->p->kobj,
27."driver");
28.if (ret)
29. sysfs_remove_link(&dev->driver->p->kobj,
30. kobject_name(&dev->kobj));
31. }
32.return ret;
33.}
34.
35.static void driver_sysfs_remove(struct device *dev)
36.{
37.struct device_driver *drv = dev->driver;
38.
39.if (drv) {
40. sysfs_remove_link(&drv->p->kobj, kobject_name(&dev->kobj));
41. sysfs_remove_link(&dev->kobj, "driver");
42. }
43.}
44.
45./**
46. * device_bind_driver - bind a driver to one device.
47. * @dev: device.
48. *
49. * Allow manual attachment of a driver to a device.
50. * Caller must have already set @dev->driver.
51. *
52. * Note that this does not modify the bus reference count
53. * nor take the bus's rwsem. Please verify those are accounted
54. * for before calling this. (It is ok to call with no other effort
55. * from a driver's probe() method.)
56. *
57. * This function must be called with @dev->sem held.
58. */
59.int device_bind_driver(struct device *dev)
60.{
61.int ret;
62.
63. ret = driver_sysfs_add(dev);
64.if (!ret)
65. driver_bound(dev);
66.return ret;
67.}
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。
[cpp]view plaincopyprint?
1.static int __device_attach(struct device_driver *drv, void *data)
2.{
3.struct device *dev = data;
4.
5.if (!driver_match_device(drv, dev))
6.return 0;
7.
8.return driver_probe_device(drv, dev);
9.}
不要小看了__device_attach()，就是在__device_attach()中既完成了匹配工作，又完成了绑定工作。bus_for_each_drv()在遍历中，如果遍历函数返回值不为0，则遍历结束。所以在__device_attach()找到并绑定了适合的驱动，就会返回1停止遍历，否则继续遍历剩余的驱动。
先来看匹配工作，这是在driver_match_device()中完成的。
[cpp]view plaincopyprint?
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亲自主持匹配工作。再具体的就只能等分析具体总线的时候了。
[cpp]view plaincopyprint?
1.int driver_probe_device(struct device_driver *drv, struct device *dev)
2.{
3.int ret = 0;
4.
5.if (!device_is_registered(dev))
6.return -ENODEV;
7.
8. pr_debug("bus: '%s': %s: matched device %s with driver %s\n",
9. drv->bus->name, __func__, dev_name(dev), drv->name);
10.
11. pm_runtime_get_noresume(dev);
12. pm_runtime_barrier(dev);
13. ret = really_probe(dev, drv);
14. pm_runtime_put_sync(dev);
15.
16.return ret;
17.}
如果driver_match_device()匹配成功了，__device_attach()就会继续调用
driver_probe_devices()完成绑定。但driver_probe_devices()又是调用really_probe()完成的。
[cpp]view plaincopyprint?
1.static atomic_t probe_count = ATOMIC_INIT(0);
2.static DECLARE_WAIT_QUEUE_HEAD(probe_waitqueue);
3.
4.static int really_probe(struct device *dev, struct device_driver *drv)
5.{
6.int ret = 0;
7.
8. atomic_inc(&probe_count);
9. pr_debug("bus: '%s': %s: probing driver %s with device %s\n",
10. drv->bus->name, __func__, drv->name, dev_name(dev));
11. WARN_ON(!list_empty(&dev->devres_head));
12.
13. dev->driver = drv;
14.if (driver_sysfs_add(dev)) {
15. printk(KERN_ERR "%s: driver_sysfs_add(%s) failed\n",
16. __func__, dev_name(dev));
17.goto probe_failed;
18. }
19.
20.if (dev->bus->probe) {
21. ret = dev->bus->probe(dev);
22.if (ret)
23.goto probe_failed;
24. } else if (drv->probe) {
25. ret = drv->probe(dev);
26.if (ret)
27.goto probe_failed;
28. }
29.
30. driver_bound(dev);
31. ret = 1;
32. pr_debug("bus: '%s': %s: bound device %s to driver %s\n",
33. drv->bus->name, __func__, dev_name(dev), drv->name);
34.goto done;
35.
36.probe_failed:
37. devres_release_all(dev);
38. driver_sysfs_remove(dev);
39. dev->driver = NULL;
40.
41.if (ret != -ENODEV && ret != -ENXIO) {
42./* driver matched but the probe failed */
43. printk(KERN_WARNING
44."%s: probe of %s failed with error %d\n",
45. drv->name, dev_name(dev), ret);
46. }
47./*
48. * Ignore errors returned by ->probe so that the next driver can try
49. * its luck.
50. */
51. ret = 0;
52.done:
53. atomic_dec(&probe_count);
54. wake_up(&probe_waitqueue);
55.return ret;
56.}
really_probe()完成的绑定工作和device_bind_driver()差不多，只是它还会调用bus->probe 或者drv->probe中定义的probe函数。
至于在really_probe()中使用probe_count保护，最后调用wake_up(&probe_waitqueue)，都是为了进行同步。
[cpp]view plaincopyprint?
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./**
17. * wait_for_device_probe
18. * Wait for device probing to be completed.
19. */
20.void wait_for_device_probe(void)
21.{
22./* wait for the known devices to complete their probing */
23. wait_event(probe_waitqueue, atomic_read(&probe_count) == 0);
24. async_synchronize_full();
25.}
driver_probe_done()检查当前是否有设备正在绑定驱动。
wait_for_device_probe()会阻塞到所有的设备绑定完驱动。
关于bus_probe_device()的过程就分析到这里，下面来看下bus_add_driver()又是怎样做的。之前我们已经知道driver_register()把绝大部分操作都移到了bus_add_driver()中来。其中
只有一点和设备与驱动的绑定相关，就是对driver_attach()的调用。
[cpp]view plaincopyprint?
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()。
[cpp]view plaincopyprint?
1.static int __driver_attach(struct device *dev, void *data)
2.{
3.struct device_driver *drv = data;
4.
5./*
6. * Lock device and try to bind to it. We drop the error
7. * here and always return 0, because we need to keep trying
8. * to bind to devices and some drivers will return an error
9. * simply if it didn't support the device.
10. *
11. * driver_probe_device() will spit a warning if there
12. * is an error.
13. */
14.
15.if (!driver_match_device(drv, dev))
16.return 0;
17.
18.if (dev->parent) /* Needed for USB */
19. down(&dev->parent->sem);
20. down(&dev->sem);
21.if (!dev->driver)
22. driver_probe_device(drv, dev);
23. up(&dev->sem);
24.if (dev->parent)
25. up(&dev->parent->sem);
26.
27.return 0;
28.}
在__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的绑定。
[cpp]view plaincopyprint?
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./*
21. * __device_release_driver() must be called with @dev->sem held.
22. * When called for a USB interface, @dev->parent->sem must be held as well.
23. */
24.static void __device_release_driver(struct device *dev)
25.{
26.struct device_driver *drv;
27.
28. drv = dev->driver;
29.if (drv) {
30. pm_runtime_get_noresume(dev);
31. pm_runtime_barrier(dev);
32.
33. driver_sysfs_remove(dev);
34.
35.if (dev->bus)
36. blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
37. BUS_NOTIFY_UNBIND_DRIVER,
38. dev);
39.
40.if (dev->bus && dev->bus->remove)
41. dev->bus->remove(dev);
42.else if (drv->remove)
43. drv->remove(dev);
44. devres_release_all(dev);
45. dev->driver = NULL;
46. klist_remove(&dev->p->knode_driver);
47.if (dev->bus)
48. blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
49. BUS_NOTIFY_UNBOUND_DRIVER,
50. dev);
51.
52. pm_runtime_put_sync(dev);
53. }
54.}
device_release_driver()还是负责加加锁，实际的工作由__device_release_driver()来完成。除了sysfs和结构中解除绑定的操作，还调用了bus->remove或者driver->remove。
虽然device注销时与driver解除绑定很简单，但driver注销要与device解除绑定就要复杂一些，因为它要与设备链表上所有的设备解除绑定。
在driver_unregister()->bus_remove_driver()中，调用了driver_detach()函数。
[cpp]view plaincopyprint?
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.
10.for (;;) {
11. spin_lock(&drv->p->klist_devices.k_lock);
12.if (list_empty(&drv->p->klist_devices.k_list)) {
13. spin_unlock(&drv->p->klist_devices.k_lock);
14.break;
15. }
16. dev_prv = list_entry(drv->p->klist_devices.k_list.prev,
17.struct device_private,
18. knode_driver.n_node);
19. dev = dev_prv->device;
20. get_device(dev);
21. spin_unlock(&drv->p->klist_devices.k_lock);
22.
23.if (dev->parent) /* Needed for USB */
24. down(&dev->parent->sem);
25. down(&dev->sem);
26.if (dev->driver == drv)
27. __device_release_driver(dev);
28. up(&dev->sem);
29.if (dev->parent)
30. up(&dev->parent->sem);
31. put_device(dev);
32. }
33.}
可以看到，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的引用计数，从这里的加锁情况，都可以看出一二。
[cpp]view plaincopyprint?
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.
8.void dev_set_drvdata(struct device *dev, void *data)
9.{
10.int error;
11.
12.if (!dev)
13.return;
14.if (!dev->p) {
15. error = device_private_init(dev);
16.if (error)
17.return;
18. }
19. dev->p->driver_data = data;
20.}
最后的dev_set_drvdata()是在dev->p->driver_data中存放驱动定义的数据。
dev_get_drvdata()是获取这个数据。
不要小看这个device_private结构中小小的driver_data，在驱动编写中总能派上大用场。当然也不是说没有driver_data就过不下去，毕竟驱动可以定义一个自己的device结构，并把通用的struct device内嵌其中，然后想放多少数据都行。可那样太麻烦，许多驱动都要
专门设置这样一个变量，索性加到通用的数据结构中。而且是直接加到device_private中，眼不见为净，方便省事。
[cpp]view plaincopyprint?
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对之前的驱动不满意，要新绑定一个。
[cpp]view plaincopyprint?
1.static int __must_check bus_rescan_devices_helper(struct device *dev,
2.void *data)
3.{
4.int ret = 0;
5.
6.if (!dev->driver) {
7.if (dev->parent) /* Needed for USB */
8. down(&dev->parent->sem);
9. ret = device_attach(dev);
10.if (dev->parent)
11. up(&dev->parent->sem);
12. }
13.return ret < 0 ? ret : 0;
14.}
bus_rescan_devices_helper()就是用来绑定新驱动的内部函数。
我们终于成功完成了对dd.c的分析，并将bus.c剩余的部分结了尾。想必大家已经充分领略了device、driver和bus的铁三角结构，下节我们将进入设备驱动模型的另一方天地。
Linux设备驱动程序设计实例2007-03-03 23:09 Linux系统中，设备驱动程序是操作系统内核的重要组成部分，在与硬件设备之间 建立了标准的抽象接口。通过这个接口，用户可以像处理普通文件一样，对硬件设 备进行打开(open)、关闭(close)、读写(read/write)等操作。通过分析和设计设 备驱动程序，可以深入理解Linux系统和进行系统开发。本文通过一个简单的例子 来说明设备驱动程序的设计。 1、程序清单 //MyDev.c 2000年2月7日编写 #ifndef __KERNEL__ #define __KERNEL__//按内核模块编译 #endif #ifndef MODULE #define MODULE//设备驱动程序模块编译 #endif #define DEVICE_NAME "MyDev" #define OPENSPK 1 #define CLOSESPK 2 //必要的头文件 #include
Linux设备驱动程序学习（5）-高级字符驱动程序操作［（2）阻 塞型I/O和休眠］ Linux设备驱动程序学习（5） -高级字符驱动程序操作［（2）阻塞型I/O和休眠］这一部分主要讨论：如果驱动程序无法立即满足请求，该如何响应？（65865346） 一、休眠 进程被置为休眠，意味着它被标识为处于一个特殊的状态并且从调度器的运行队列中移走。这个进程将不被在任何CPU 上调度，即将不会运行。直到发生某 些事情改变了那个状态。安全地进入休眠的两条规则： （1）永远不要在原子上下文中进入休眠，即当驱动在持有一个自旋锁、seqlock或者RCU 锁时不能睡眠；关闭中断也不能睡眠。持有一个信号量时休眠是 合法的，但你应当仔细查看代码：如果代码在持有一个信号量时睡眠，任何其他的等待这个信号量的线程也会休眠。因此发生在持有信号量时的休眠必须短暂， 而且决不能阻塞那个将最终唤醒你的进程。 （2）当进程被唤醒，它并不知道休眠了多长时间以及休眠时发生什么；也不知道是否另有进程也在休眠等待同一事件，且那个进程可能在它之前醒来并获取了 所等待的资源。所以不能对唤醒后的系统状态做任何的假设，并必须重新检查等待条件来确保正确的响应。 除非确信其他进程会在其他地方唤醒休眠的进程，否则也不能睡眠。使进程可被找到意味着：需要维护一个称为等待队列的数据结构。它是一个进程链表，其中饱含了等待某个特定事件的所有进程。在Linux 中，一个等待队列由一个wait_queue_head_t 结构体来管理，其定义在
第31卷 第2期 2008年4月 电子器件 Ch in es e Jo u rnal Of Electro n Devi ces Vol.31 No.2Apr.2008 Design and Implementation of Audio Driver for Embedded Linux System YU Yue,YA O G uo -liang * (N ational A S I C S ystem Eng ine ering Center ,S outhe ast Unive rsity ,N anj ing 210096,China) Abstract:This paper intro duces the fundam ental principle and architecture of the audio system w hich con -sists of the CODEC UCB1400and the 805puls,and describes the design of audio dev ice dr iv er based on Audio Codec .97for Embedded Linux System.The paper focuses o n the implementatio n of the DM A trans -port and ioctl interface.T he audio dr iv e is running w ell in actual Embedded Linux system equipments.Key words:805plus;embedded Linux;Audio A C .97driver;DM A;ioctl interface EEACC :1130B 嵌入式Linux 系统中音频驱动的设计与实现 虞 跃,姚国良 * (东南大学国家专用集成电路系统工程中心,南京210096) 收稿日期:2007-07-09 作者简介:虞 跃(1982-),男,东南大学电子工程系国家专用集成电路工程技术研究中心硕士研究生,研究方向为嵌入式系统设计; 姚国良(1979-),男,东南大学电子工程系博士研究生,yuyueo@https://www.doczj.com/doc/3912868501.html,. 摘 要:介绍了由805puls 处理器和U CB1400编解码芯片构成的音频系统体系结构及工作原理,接着阐述了嵌入式Linux 操作系统下基于A C .97协议标准的音频设备驱动程序的设计与实现。其中着重讲述了采用循环缓冲区进行音频数据的DM A 传输流程以及ioctl 接口的实现。此设计方案已在嵌入式L inux 系统中得到使用,运行效果良好。 关键词:805plus;嵌入式L inux ;AC .97音频驱动;DM A;ioctl 接口中图分类号:TP391 文献标识码:A 文章编号:1005-9490(2008)02-0709-03 嵌入式音频系统广泛应用于GPS 自动导航、PDA,3G 手机等移动信息终端,具备播放、录音功能的音频系统的应用使得移动信息终端上视听娱乐IP 电话、音频录制等成为可能,并推动了移动信息终端设备的发展。 在软件上,嵌入式操作系统的新兴力量Linux 的开源性,内核可定制等优点吸引了许多的开发者与开发商。它是个和U nix 相似、以核心为基础的、完全内存保护、多任务多进程的操作系统。支持广泛的计算机硬件,包括X86,A lpha,Sparc,M IPS,PPC,ARM ,NEC,MOT OROLA 等现有的大部分芯片[1]。 本文针对805puls 微处理器选用Philips 公司的编解码芯片(CODEC)U CB1400,构建了基于Au -dio Codec .97(AC .97)标准的音频系统。并介绍了该音频系统在Linux 操作系统2.4.19内核下驱动 程序的实现技术。 1 音频系统构架 1.1 微处理器805plus 805plus 是东南大学ASIC 系统工程技术研究中心和北京大学微处理器研究开发中心共同设计和开发的32bit 嵌入式微处理器,是采用H ar vard 结构的RISC 处理器。内部采用五级流水线结构,兼容16bit 和32bit 的指令系统805plus 嵌入式微处理器集成了存储接口EMI,时钟和功耗管理PM C,中断控制器INTC,通用定时器T IM ER,脉宽调制器PWM,实时时钟RT C,通用串口UA RT,LCD 控制器LCDC,AC .97控制器,同步外设接口SPI 。1.2 AC .97协议标准[2] AC'97协议标准是一套关于A C'97数字音频处理(AC'97Digital Controller)、AC '97数字串口(AC
实现如下的功能: --字符设备驱动程序的结构及驱动程序需要实现的系统调用 --可以使用cat命令或者自编的readtest命令读出"设备"里的内容 --以8139网卡为例,演示了I/O端口和I/O内存的使用 本文中的大部分内容在Linux Device Driver这本书中都可以找到, 这本书是Linux驱动开发者的唯一圣经。 ================================================== ===== 先来看看整个驱动程序的入口,是char8139_init(这个函数 如果不指定MODULE_LICENSE("GPL", 在模块插入内核的 时候会出错,因为将非"GPL"的模块插入内核就沾污了内核的 "GPL"属性。 module_init(char8139_init; module_exit(char8139_exit; MODULE_LICENSE("GPL"; MODULE_AUTHOR("ypixunil"; MODULE_DESCRIPTION("Wierd char device driver for Realtek 8139 NIC"; 接着往下看char8139_init( static int __init char8139_init(void {
int result; PDBG("hello. init.\n"; /* register our char device */ result=register_chrdev(char8139_major, "char8139", &char8139_fops; if(result<0 { PDBG("Cannot allocate major device number!\n"; return result; } /* register_chrdev( will assign a major device number and return if it called * with "major" parameter set to 0 */ if(char8139_major == 0 char8139_major=result; /* allocate some kernel memory we need */ buffer=(unsigned char*(kmalloc(CHAR8139_BUFFER_SIZE, GFP_KERNEL; if(!buffer { PDBG("Cannot allocate memory!\n"; result= -ENOMEM;
CAN总线在嵌入式Linux下驱动程序的实现 时间：2009-11-05 09:41:22 来源：微计算机信息作者：黄捷峰蔡启仲郭毅锋田小刚 1 引言 基于嵌入式系统设计的工业控制装置，在工业控制现场受到各种干扰，如电磁、粉尘、天气等对系统的正常运行造成很大的影响。在工业控制现场各个设备之间要经常交换、传输数据，需要一种抗干扰性强、稳定、传输速率快的现场总线进行通信。文章采用CAN总线，基于嵌入式系统32位的S3C44B0X微处理器，通过其SPI接口，MCP2510 CAN控制器扩展CAN总线；将嵌入式操作系统嵌入到S3C44B0X微处理器中，能实现多任务、友好图形用户界面；针对S3C44B0X微处理器没有内存管理单元MMU，采用uClinux嵌入式操作系统。这样在嵌入式系统中扩展CAN设备关键技术就是CAN设备在嵌入式操作系统下驱动程序的实现。文章重点解决了CAN总线在嵌入式操作系统下驱动程序实现的问题。对于用户来说，CAN设备在嵌入式操作系统驱动的实现为用户屏蔽了硬件的细节，用户不用关心硬件就可以编出自己的用户程序。实验结果表明驱动程序的正确性，能提高整个系统的抗干扰能力，稳定性好，最大传输速率达到1Mb/s；硬件的错误检定特性也增强了CAN的抗电磁干扰能力。 2 系统硬件设计 系统采用S3C44B0X微处理器,需要扩展CAN控制器。常用的CAN控制器有SJA1000和MCP2510,这两种芯片都支持CAN2.0B标准。SJA1000采用的总线是地址线和数据线复用的方式，但是嵌入式处理器外部总线大多是地址线和数据线分开的结构，这样每次对SJA1000操作时需要先后写入地址和数据2次数据，而且SJA1000使用5V逻辑电平。所以应用MCP2510控制器进行扩展，收发器采用82C250。MCP2510控制器特点：1.支持标准格式和扩展格式的CAN数据帧结构（CAN2.0B）；2.0～8字节的有效数据长度，支持远程帧；3.最大1Mb/s的可编程波特率；4.2个支持过滤器的接受缓冲区，3个发送缓冲区； 5.SPI高速串行总线，最大5MHz； 6.3～5.5V宽电压范围供电。MCP2510工作电压为3.3V，能够直接与S3C44B0X微处理器I/O口相连。为了进一步提高系统抗干扰性，可在CAN控制器和收发器之间加一个光隔6N137。其结构原理框图如图1： 图1.S3C44B0X扩展CAN结构框图图2.字符设备注册表 3 CAN设备驱动程序的设计 Linux把设备看成特殊的文件进行管理，添加一种设备，首先要注册该设备，增加它的驱动。设备驱动程序是操作系统内核与设备硬件之间的接口，并为应用程序屏蔽了硬件细节。在linux中用户进程不能直接对物理设备进行操作，必须通过系统调用向内核提出请求，
本文主要描述在EVB335X-II以Device Tree的方式移植新TI官网AM335X系列最新的linux-3.14.43版本内核以及移植Debian文件系统的过程及遇到的一些问题。整个Device Tree牵涉面比较广，即增加了新的用于描述设备硬件信息的文本格式(即.dts文件)，又增加 了编译这一文本的工具，同时Bootloader也需要支持将编译后的Device Tree传递给Linux 内核。以下是修改步骤： 一、修改uboot，支持Device Tree EVB335X-II在linux-3.2版本内核移植的时候已经有uboot，因此只需在该uboot上增加Device Tree支持即可，以下是修改步骤： 1、修改include/configs/com335x.h文件，增加支持DT的宏定义： /* Flattened Device Tree */ #define CONFIG_OF_LIBFDT 2、修改uboot启动参数，增加dtb文件的加载和启动（由于目前只是移植EMMC版本的EVB335X-II，因此只需修改EMMC的启动参数即可，大概在405行），修改如下： #elif defined(CONFIG_EMMC_BOOT) #define CONFIG_BOOTCOMMAND \ "run mmcboot;" #define CONFIG_EXTRA_ENV_SETTINGS \ "lcdtype=AUO_AT070TN94\0" \ "console=ttyO0,115200n8\0" \ "mmcroot=/dev/mmcblk0p2 rw\0" \ "mmcrootfstype=ext4 rootwait\0" \ "mmcargs=setenv bootargs console=${console} noinitrd root=${mmcroot} rootfstype=${mmcrootfstype} lcdtype=${lcdtype} consoleblank=0\0" \ "mmcdev=" MMCDEV "\0" \ "loadaddr=0x81000000\0" \ "dtbfile=evb335x-ii-emmc.dtb\0" \ "bootenv=uEnv.txt\0" \ "bootpart=" BOOTPART "\0" \ "loadbootenv=load mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \ "importbootenv=echo Importing environment from mmc ...; " \ "env import -t $loadaddr ${filesize}\0" \ "loadaddr-dtb=0x82000000\0" \ "loadimage=load mmc ${bootpart} ${loadaddr} uImage\0" \ "loaddtb=load mmc ${bootpart} ${loadaddr-dtb} ${dtbfile}\0" \ "mmcboot=mmc dev ${mmcdev}; " \ "if mmc rescan; then " \ "echo SD/MMC found on device ${mmcdev};" \ "if run loadbootenv; then " \ "echo Loaded environment from ${bootenv};" \ "run importbootenv;" \ "fi;" \ "run mmcargs;" \
Linux设备驱动程序学习（18）－USB 驱动程序（三） (2009-07-14 11:45) 分类：Linux设备驱动程序 USB urb （USB request block） 内核使用2.6.29.4 USB 设备驱动代码通过urb和所有的 USB 设备通讯。urb用 struct urb 结构描述（include/linux/usb.h ）。 urb以一种异步的方式同一个特定USB设备的特定端点发送或接受数据。一个USB 设备驱动可根据驱动的需要，分配多个 urb 给一个端点或重用单个 urb 给多个不同的端点。设备中的每个端点都处理一个 urb 队列, 所以多个 urb 可在队列清空之前被发送到相同的端点。 一个 urb 的典型生命循环如下: （1）被创建； （2）被分配给一个特定 USB 设备的特定端点； （3）被提交给 USB 核心； （4）被 USB 核心提交给特定设备的特定 USB 主机控制器驱动； （5）被 USB 主机控制器驱动处理, 并传送到设备； （6）以上操作完成后，USB主机控制器驱动通知 USB 设备驱动。 urb 也可被提交它的驱动在任何时间取消；如果设备被移除，urb 可以被USB 核心取消。urb 被动态创建并包含一个内部引用计数，使它们可以在最后一个用户释放它们时被自动释放。 struct urb
struct list_head urb_list;/* list head for use by the urb's * current owner */ struct list_head anchor_list;/* the URB may be anchored */ struct usb_anchor *anchor; struct usb_device *dev;/* 指向这个 urb 要发送的目标 struct usb_device 的指针,这个变量必须在这个 urb 被发送到 USB 核心之前被USB 驱动初始化.*/ struct usb_host_endpoint *ep;/* (internal) pointer to endpoint */ unsigned int pipe;/* 这个 urb 所要发送到的特定struct usb_device 的端点消息,这个变量必须在这个 urb 被发送到 USB 核心之前被 USB 驱动初始化.必须由下面的函数生成*/ int status;/*当 urb开始由 USB 核心处理或处理结束, 这个变量被设置为 urb 的当前状态. USB 驱动可安全访问这个变量的唯一时间是在 urb 结束处理例程函数中. 这个限制是为防止竞态. 对于等时 urb, 在这个变量中成功值(0)只表示这个 urb 是否已被去链. 为获得等时 urb 的详细状态, 应当检查 iso_frame_desc 变量. */ unsigned int transfer_flags;/* 传输设置*/ void*transfer_buffer;/* 指向用于发送数据到设备(OUT urb)或者从设备接收数据(IN urb)的缓冲区指针。为了主机控制器驱动正确访问这个缓冲, 它必须使用 kmalloc 调用来创建, 不是在堆栈或者静态内存中。对控制端点, 这个缓冲区用于数据中转*/ dma_addr_t transfer_dma;/* 用于以 DMA 方式传送数据到 USB 设备的缓冲区*/ int transfer_buffer_length;/* transfer_buffer 或者 transfer_dma 变量指向的缓冲区大小。如果这是 0, 传送缓冲没有被 USB 核心所使用。对于一个 OUT 端点, 如果这个端点大小比这个变量指定的值小, 对这个USB 设备的传输将被分成更小的块，以正确地传送数据。这种大的传送以连续的 USB 帧进行。在一个 urb 中提交一个大块数据, 并且使 USB 主机控制器去划分为更小的块, 比以连续地顺序发送小缓冲的速度快得多*/
Linux2.6设备驱动常用的接口函数（一） ----字符设备 刚开始，学习linux驱动，觉得linux驱动很难，有字符设备，块设备，网络设备，针对每一种设备其接口函数，驱动的架构都不一样。这么多函数，要每一个的熟悉，那可多难啦！可后来发现linux驱动有很多规律可循，驱动的基本框架都差不多，再就是一些通用的模块。 基本的架构里包括：加载，卸载，常用的读写，打开，关闭，这是那种那基本的咯。利用这些基本的功能，当然无法实现一个系统。比方说：当多个执行单元对资源进行访问时，会引发竞态；当执行单元获取不到资源时，它是阻塞还是非阻塞？当突然间来了中断，该怎么办？还有内存管理，异步通知。而linux 针对这些问题提供了一系列的接口函数和模板框架。这样，在实际驱动设计中，根据具体的要求，选择不同的模块来实现其功能需求。 觉得能熟练理解，运用这些函数，是写号linux设备驱动的第一步。因为是设备驱动，是与最底层的设备打交道，就必须要熟悉底层设备的一些特性，例如字符设备，块设备等。系统提供的接口函数，功能模块就像是工具，能够根据不同的底层设备的的一些特性，选择不同的工具，方能在linux驱动中游刃有余。 最后就是调试，这可是最头疼的事。在调试过程中，总会遇到这样，那样的问题。怎样能更快，更好的发现并解决这些问题，就是一个人的道行咯！我个人觉得： 发现问题比解决问题更难！ 时好时坏的东西，最纠结！ 看得见的错误比看不见的错误好解决！ 一：Fops结构体中函数： ①ssize_t (*read) (struct file *, char __user *, size_t, loff_t *); 用来从设备中获取数据. 在这个位置的一个空指针导致 read 系统调用以-EINVAL("Invalid argument") 失败. 一个非负返回值代表了成功读取的字节数( 返回值是一个 "signed size" 类型, 常常是目标平台本地的整数类型). ②ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *); 发送数据给设备. 如果 NULL, -EINVAL 返回给调用 write 系统调用的程序. 如果非负, 返回值代表成功写的字节数 ③loff_t (*llseek) (struct file *, loff_t, int); llseek 方法用作改变文件中的当前读/写位置, 并且新位置作为(正的)返回值. loff_t 参数是一个"long offset", 并且就算在 32位平台上也至少 64 位宽. 错误由一个负返回值指示. 如果这个函数指针是 NULL, seek 调用会以潜在地无法预知的方式修改 file 结构中的位置计数器( 在"file 结构" 一节中描述). ④int (*open) (struct inode *, struct file *);
Linux设备驱动模型之platform总线深入浅出 在Linux2.6以后的设备驱动模型中，需关心总线，设备和驱动这三种实体，总线将设备和驱动绑定。在系统每注册一个设备的时候，会寻找与之匹配的驱动；相反，在系统每注册一个驱动的时候，会寻找与之匹配的设备，而匹配由总线完成。 对于依附在USB、PCI、I2C、SPI等物理总线来这些都不是问题。但是在嵌入式系统里面，在Soc系统中集成的独立外设控制器，挂接在Soc内存空间的外设等却不依附在此类总线。基于这一背景，Linux发明了一种总线，称为platform。相对于USB、PCI、I2C、SPI等物理总线来说，platform总线是一种虚拟、抽象出来的总线，实际中并不存在这样的总线。 platform总线相关代码：driver\base\platform.c 文件相关结构体定义：include\linux\platform_device.h 文件中 platform总线管理下最重要的两个结构体是platform_device和platform_driver 分别表示设备和驱动在Linux中的定义如下一：platform_driver //include\linux\platform_device.h struct platform_driver { int (*probe)(struct platform_device *); //探测函数，在注册平台设备时被调用int (*remove)(struct platform_device *); //删除函数，在注销平台设备时被调用void (*shutdown)(struct platform_device *); int (*suspend)(struct platform_device *, pm_message_t state); //挂起函数，在关机被调用int (*suspend_late)(struct platform_device *, pm_message_t state); int (*resume_early)(struct platform_device *); int (*resume)(struct platform_device *);//恢复函数，在开机时被调用struct device_driver driver;//设备驱动结构}; 1 2 3 4 5 6 7 8
20150526 echo adfkjeroiu > /var/www/html/index.html service httpd restart ifconfig XXX.XXX.XXX.XXX elinks XXX.XXX.XXX.XXX web地址栏：XXX.XXX.XXX.XXX 20150527 方法一：Setup 设置IP 方法二：vim /etc/sysconfig/network-XXX/ifcfg-eth0 onboot=no改onboot=yes service network restart 虚拟机中安装2个linux，有时2个linux无法连接网络，即使是DHCP自动获取，也不可以；解决办法：打开其中一个linux虚拟机，单机“右下角-小电脑图标” —“设置”—“桥接模式(B)；直接连接屋里网络” ，确定即可； 20150528 more /etc/issue 查看当前linux是centos还是redhat; man 命令查看当前命令的使用方法及参数 table 当一个命令不记得全部字母，可以双击table补齐； ctrl +c 终止当前程序 ctrl +l 清屏 20150529 ls -l查看命令；(-l显示更多属性) ls –a 查看隐藏文件； cp -r /etc/aaa /home/bbb复制/etc下的aaa 到/home下，并且改名bbb; (-r是整个文件夹的意思，如果，没有-r是复制单个文件) mv /etc/aaa /home/bbb 移动/etc下的aaa 到/home下，并且改名bbb；
rm –r 删除一个文件；（如果要是一个文件夹，就有询问yes或no） rm –rf 删除一个文件夹；（如果要是一个文件夹，就无询问） touch 创建文件； pwd 查看当前路径； cd.. 返回相对路径； cd / 返回绝对路径； cd- 返回刚才的路径； su – root或其它用户切换用户； mkdir 创建新目录； cat 查看文件内容； more或less 逐屏查看文件内容； useradd 新添加的用户，在没有更改密码前，无法登陆； passwd 更改密码；但是，密码必须符合复杂性； groupadd 添加一个组； 20150602 w 查看谁登陆过本计算机以及对方的IP； last 查看用户的登录日志； lastlog 查看每个用户最后登录的情况；（一般用于电脑被黑了之后）； more /var/log/secure who /var/log/wtmp 干了些什么？ root账户下输入su - username 切换到username下输入 history 能看到这个用户历史命令，默认最近的1000条 Linux查看History记录加时间戳小技巧 1.[root@servyou_web ~]# export HISTTIMEFORMAT="%F %T `whoami` " 2.[root@servyou_web ~]# history | tail 3. 1014 2011-06-22 19:17:29 root 15 2011-06-22 19:13:02 root ./test.sh 4. 1015 2011-06-22 19:17:29 root 16 2011-06-22 19:13:02 root vim test.sh 5. 1016 2011-06-22 19:17:29 root 17 2011-06-22 19:13:02 root ./test.sh 6. 1017 2011-06-22 19:17:29 root 18 2011-06-22 19:13:02 root vim test.sh 7. 1018 2011-06-22 19:17:29 root 19 2011-06-22 19:13:02 root ./test.sh 8. 1019 2011-06-22 19:17:29 root 20 2011-06-22 19:13:02 root vim test.sh 9. 1020 2011-06-22 19:17:29 root 21 2011-06-22 19:13:02 root ./test.sh
12.29 Linux系统 Linux是真正的多用户、多任务操作系统。它继承了UNIX系统的主要特征，具有强大的信息处理功能，特别在Internet和Intranet的应用中占有明显优势。是一个完整的UNIX类操作系统。它允许多个用户同时在一个系统上运行多道程序。真正的32位操作系统。 用户接口 用户接口定义了用户和计算机交互作用的方式。Linux操作系统提供4种不同的用户接口。命令行接口 命令行是为具有操作系统使用经验，熟悉所用命令和系统结构的人员设计的。功能强大，使用方便的命令行是UNIX/Linux系统的一个显著特征。支持命令行的系统程序是命令解释程序。它的主要功能是接收用户输入的命令，然后予以解释并执行。 “$ ”是系统提示符。 在UNIX/Linux系统中，通常将命令解释程序称为shell。各种Linux环境下都安装了多种shell。这些shell由不同的人编写并得到一部分用户的青睐，各有其优势，最常用的几种是Bourne shell（sh），C shell（csh），Bourne Again shell（bash）和Korn shell（ksh）。红旗Linux 的默认shell是bash。 Bash 菜单 图形用户接口 程序接口 程序接口也称为系统调用接口。用户在自己的C程序中使用系统调用，从而获得系统提供的更基层的服务。 系统调用是操作系统内核与用户程序，应用程序之间的接口。在UNIX/Linux系统中，系统调用以C函数的形式出现。例如：fd=fopen(“file1.c”,2);其中，open是系统调用。 所有内核之外的程序都必须经由系统调用才能获得操作系统的服务。系统调用只能在C程序中使用，不能作为命令在终端上执行。由于系统调用能直接进入内核执行，所以其执行效率高。 Linux的版本 Linux有两种版本：核心（Kernel）版本和发行（Distribution）版本。 核心版本 核心版本主要是Linux的内核。Linux内核的官方版本由Linus Torvalds本人维护着。核心版本的序号由三部分数字构成，其形式为：major.minor.patchlevel 其中，major是主版本号，minor是次版本号，二者共同构成了当前核心版本好；patchlevel 表示对当前版本的修订次数。例如：2.6.34表示对2.6核心版本的第34次修订。
Linux设备驱动程序学习（20）-内存映射和DMA-基本概念 (2011-09-25 15:47) 标签: 虚拟内存设备驱动程序Linux技术分类：Linux设备驱动程序 这部分主要研究 Linux 内存管理的基础知识, 重点在于对设备驱动有用的技术. 因为许多驱动编程需要一些对于虚拟内存（VM）子系统原理的理解。 而这些知识主要分为三个部分： 1、 mmap系统调用的实现原理：它允许设备内存直接映射到一个用户进程地址 空间. 这样做对一些设备来说可显著地提高性能. 2、与mmap的功能相反的应用原理：内核态代码如何跨过边界直接存取用户空间的内存页. 虽然较少驱动需要这个能力. 但是了解如何映射用户空间内存到内 核(使用 get_user_pages)会有用. 3、直接内存存取( DMA ) I/O 操作, 它提供给外设对系统内存的直接存取. 但所有这些技术需要理解 Linux 内存管理的基本原理, 因此我将先学习VM子 系统的基本原理. 一、Linux的内存管理 这里重点是 Linux 内存管理实现的主要特点，而不是描述操作系统的内存管理理论。Linux虚拟内存管理非常的复杂，要写可以写一本书：《深入理解Linux 虚拟内存管理》。学习驱动无须如此深入, 但是对它的工作原理的基本了解是必要的. 解了必要的背景知识后,才可以学习内核管理内存的数据结构. Linux是一个虚拟内存系统（但是在没有MMU的CPU中跑的ucLinux除外）, 意味着在内核启动了MMU 之后所有使用的地址不直接对应于硬件使用的物理地址，这些地址（称之为虚拟地址）都经过了MMU转换为物理地址之后再从CPU的内存总线中发出，读取/写入数据. 这样 VM 就引入了一个间接层, 它是许多操作成为可能： 1、系统中运行的程序可以分配远多于物理内存的内存空间，即便单个进程都可拥有一个大于系统的物理内存的虚拟地址空间. 2、虚拟内存也允许程序对进程的地址空间运用多种技巧, 包括映射程序的内存到设备内存.等等～～～ 1、地址类型 Linux 系统处理几种类型的地址, 每个有它自己的含义： 用户虚拟地址：User virtual addresses，用户程序见到的常规地址. 用户地址在长度上是 32 位或者 64 位, 依赖底层的硬件结构, 并且每个进程有它自己 的虚拟地址空间.
LED驱动学习： 是一个char字符类型的驱动 //配置模式为输出端口 static unsigned int led_cfg_table [] = { S3C2410_GPB5_OUTP, S3C2410_GPB6_OUTP, S3C2410_GPB7_OUTP, S3C2410_GPB8_OUTP, }; s3c2410_gpio_cfgpin(S3C2410_GPB5, S3C2410_GPB5_OUTP); s3c2410_gpio_cfgpin(37, 0x01 << 10); 这个在\arch\arm\mach-s3c2410\include\mach\regs-gpio.h中定义 #define S3C2410_GPB5 S3C2410_GPIONO(S3C2410_GPIO_BANKB, 5) #define S3C2410_GPB5_INP (0x00 << 10) #define S3C2410_GPB5_OUTP (0x01 << 10) #define S3C2410_GPB5_nXBACK (0x02 << 10) S3C2410_GPIONO(S3C2410_GPIO_BANKB, 5) #define S3C2410_GPIONO(bank,offset) ((bank) + (offset)) #define S3C2410_GPIO_BANKA (32*0) #define S3C2410_GPIO_BANKB(32*1) static int __init dev_init(void) { int ret; int i; for (i = 0; i < 4; i++) { s3c2410_gpio_cfgpin(led_table[i], led_cfg_table[i]); s3c2410_gpio_setpin(led_table[i], 0); } 在驱动的初始化函数中经常看到，__init 前缀，这个在下面文件中定义 file:/include/linux/init.h ? /* These macros are used to mark some functions or ?* initialized data (doesn't apply to uninitialized data) ?* as `initialization' functions. The kernel can take this ?* as hint that the function is used only during the initialization ?* phase and free up used memory resources after ?* ?* Usage: ?* For functions: ?* ?* You should add __init immediately before the function name, like: ?*
1.ls：查看当前路径下的文件以及文件夹的名字 2.ls /bin：查看根目录下的bin文件夹的东西 3.cd Desktop进入到Desktop文件夹 4.cd ..跳转到当前路径的上一层 5.pwd：显示当前操作的路径（绝对路径） 6.clear：清屏 7.绝对路径：/home/python 8.相对路径：cd downloads 9..表示当前路径 10...表示上一层路径 11.c d -：跳转到上一层所在的路径 12.t ab自动补全 13.t ouch 1.txt 创建文件 14.l s * 表示显示所有文件 15.l s *.txt 表示显示以所有.txt结尾的文件 16.l s*.t[xn]t 表示显示以txt或者tnt结尾的所有文件 17.m ore 查看文件的内容 18.l s–alh | more 查看文件的内容并以管道符号进行连接 19.c d ～切换到当前用户的主目录 20.m kdir 创建文件夹 21.m kdira/b/c –p 连续创建文件夹 22.t ree 以目录数的方式显示
23.r mdir 删除文件夹（必须是空目录） 24.实物图操作的文件不会被删除直接进回收站 25.用命令删除的文件是不会进入回收站的 26.r m 删除文件/文件夹 27.r m haha.txt –r 直接删除文件夹（-r表示递归的删除） 28.r m haha.txt –i 给将删除的文件一个删除提示 29.r m haha.txt –f 强制删除 30.l inux建立链接影响（相当于创建windows下的快捷方式） 31.l n 01.txt 创建快捷方式 32.g edit 01.txt 编辑文件的内容 33.c at 01.txt 查看所编辑的内容 34.c at 01.txt > 02.txt 合并文件 35.g rep–n ‘a’grep.txt 搜素文件当中带a的文件 36.g rep–i ‘a’grep.txt搜素文件当中带a的文件（忽略大小写） 37.–-help 查找帮助文档 38.f ind 查找文件 39.c p a b 将a文件下的内容整体复制到b文件夹下（无效的文 件无法复制） 40.c p a/* b 将a文件夹下的所有内容复制到b文件夹下 41.m v a b 将a文件夹整体移动到b文件夹下 42.–v 显示移动进度 43.–I 表示操作的时候显示的提示（y表示确定）
嵌入式linux android驱动工程师面试题总汇 1.嵌入式系统中断服务子程序(ISR)收藏中断是嵌入式系统中重要的组成部分，这导致了很多编译开发商提供一种扩展—让标准C支持中断。具代表事实是，产生了一个新的关键字__interrupt。下面的代码就使用了__interrupt关键字去定义了一个中断服务子程序(ISR)，请评论一下这段代码的。 2.C语言中对位的操作，比如对a的第三位清0，第四位置1.本来应该会的，一犯晕写反了，以后注意！ #define BIT3 (1<<3) #define BIT4 (1<<4) a &= ~BIT3;a |= BIT4; 3.考到volatile含义并举例： 理解出错，举了很具体的例子，连程序都搬上去了，有些理解不深的没举出来…… volatile表示这个变量会被意想不到的改变，每次用他的时候都会小心的重新读取一遍，不适用寄存器保存的副本。 volatile表示直接存取原始地址 例： 并行设备的硬件寄存器（状态寄存器） 在多线程运行的时候共享变量也要时时更新 一个中断服务子程序中访问到的的非自动变量（不太清楚，正在查找资料ing……） 4.要求设置一绝对地址为0x67a9的整型变量的值为0xaa66
当时我的写法： #define AA *（volatile unsigned long *）0xaa66AA = 0x67a9; 答案： int *ptr =（int *）0xaa66； *ptr = 0x67a9； 我感觉自己写的应该不算错吧（自我感觉，还请达人指正），我写的适合裸机下用，当做寄存器用，而答案就是适合在操作系统下的写法。 1. linux内核里面，内存申请有哪几个函数，各自的区别？ 2. IRQ和FIQ有什么区别，在CPU里面是是怎么做的？ 3. int *a; char *b; a 和b本身是什么类型？ a、b里面本身存放的只是一个地址，难道是这两个地址有不同么？ 4.xx的上半部分和下半部分的问题： 讲下分成上半部分和下半部分的原因，为何要分？讲下如何实现？ 5.内核函数mmap的实现原理，机制？ 6.驱动里面为什么要有并发、互斥的控制？如何实现？讲个例子？ 7. spinlock自旋锁是如何实现的？ 8.任务调度的机制？ 【二、本人碰到】