蜗窝科技

对于第一个问题： CMWQ兼容旧的接口，因此也支持create_workqueue，定义如下： #define create_workqueue(name) alloc_workqueue("%s", WQ_MEM_RECLAIM, 1, (name)) 在旧的workqueue机制中，create_workqueue意味着要创建per cpu的worker thread，对应到CMWQ中就是创建一个最大并发是1的bound workqueue。 对于第二个问题： 后续的CMWQ的文档会描述，敬请期待。

@gzz：如果内核已经创建了设备节点，虽然udev通过netlink收到uevent，我相信它也不会重复创建设备节点，当然，如果需要udev可以修改 如果对启动速度没有那么在意的话，可以不配置devtmpfs。

@passerby：次级GIC会使用ROOT GIC一个中断线，通过向这个中断线注册一个中断服务函数A。当这个中断线发生中断后肯定就是次级GIC上的中断引发的，那A函数就会去读取次级GIC中断位状态，从而知道次级GIC哪个位发生了中断。这样就可以调用相应次级GIC的中断服务函数了。

@gzz：我在高通里面看到，GPIO INT CONTROLLER和GIC的级联，也许能给你启发。 高通GPIO的控制器会连到GIC 208引脚上，在初始化的时候就会在gpio ontroller init的时候注册这个GIC 208的中断。当GPIO中断发生时，其实会触发GIC的gic_handle_irq处理函数。gic_handle_irq函数就会去读取当前谁发生了中断，最后会发现208引脚中断，然后执行208中断的handler，最后执行desc->action函数。 这个时候gpio controller在初始化时候通过devm_request_irq就会去检查GPIO CONTROLLER的相应位从而知道是哪个GPIO 哪个引脚发生中断，最后调用 generic_handle_irq(virq); 去执行你在gpio request_irq时注册的GPIO 中断函数。

@linuxer：我理解你的意思了，应该是内核启动时，有的设备节点是可以创建了的，因为是编译在内核中的，这些设备节点就需要提前创建，也可以加快处理速度。而一边在启动脚本中add的设备节点，理论应该是udev来创建的吧。

前排占座，有个2个问题。 1、现在create_workqueue还在驱动中被使用(kernel 3.10)，这个函数是不是被用alloc_workqueue重新实现过得？ 2、按照你上面A B C D 四个work的说法，感觉只有worker pool只会有一个线程会处理work，但是我在work_threader里看到，如果woker_pool->nr_idle = 0 并且 pool-nr_running != 0就会在manage_workers中创建线程，任务会并发处理。能够详细的解释下吗？

@gzz：可以看到，级联时domain的中断处理： static void gic_handle_cascade_irq(unsigned int irq, struct irq_desc *desc) { struct gic_chip_data *chip_data = irq_get_handler_data(irq); struct irq_chip *chip = irq_get_chip(irq); unsigned int cascade_irq, gic_irq; unsigned long status; chained_irq_enter(chip, desc); raw_spin_lock(&irq_controller_lock); status = readl_relaxed(gic_data_cpu_base(chip_data) + GIC_CPU_INTACK);//级联的操作对应的chip controll 需要获取gic_irq raw_spin_unlock(&irq_controller_lock); gic_irq = (status & 0x3ff); if (gic_irq == 1023) goto out; cascade_irq = irq_find_mapping(chip_data->domain, gic_irq);//找到该级controll下hw irq对应的irq num if (unlikely(gic_irq < 32 || gic_irq > 1020)) do_bad_IRQ(cascade_irq, desc); else generic_handle_irq(cascade_irq);//子controller下hw对应的回调处理 out: chained_irq_exit(chip, desc); } 也是一个中断号，所有我更加猜测，假设就是简单的一对一的映射，root gic controller（比如0-64）+次 controller(对应65-128).这样两者的中断号就不会重合？

还是一个原来的疑惑： 假设一个root gic controll下面挂了另一个gic controller。比如是SPI64的。那么如果将次controller的上的2个中断进行request_irq时，是不是都用的irq_num SPI64就行了呢？ 如果是那么如何去区分两者的handler呢。 因为chain的irq中断回调处理，还是去找的irq_desc然后找irq_handler.但次controller上的两个不同中断，难道有他自己的一直irq_desc?还是一个domain就一张irq_num? 是不是级联的时候，中断号就是连续的呢，比如root就是0-64.然后次controller是65-128？这样貌似次controller上的2个中断号就可以分为65,66假设。不用读是64了吧？ 请指教下。都是假设，但有这种情况，内核是怎么处理的，因为request时没看到有对级联controller的单独处理？

@linuxer：恩，我看到是Android的内核的uevent处理机制，他内部实现是会去看sysfs下面class/devices等是否含有uevent属性文件，暂时是不借助dev文件的。然后如果有找到就去触发一次底层block的uevent事件的上报，基于netlink这种网络机制。因为一般在init内核时，uevent是没起来的。 不过，我暂时不知道普通linux的udev处理是什么机制。应该是你说的那种机制吧。 至于你说的devtmpfs，我是不是可以让系统不支持呢，比如在Android下的linux内核，是不是有什么CONFIG之类可配置。

写的很好，对我帮助特别大，我要把网站上所有的文章都读过来。