蜗窝科技

问下，我的kernel版本是3.0.35，里面搜early_ioremap,搜到的都是ia64和x86平台的，arm平台没有实现这个函数。 还有我的这个版本内核early_prink的实现，最终通过CONFIG_DEBUG_LL对应的debug.S 里面的几个汇编函数来实现串口寄存器级别的发送字符操作过程，你文章中的early printk的实现应该和CONFIG_DEBUG_LL没有任何关系。 是不是高版本的Linux内核 早期串口输出字符已经完全脱离了CONFIG_DEBUG_LL？而且高版本的也有arm平台的early_ioremap的实现，可以让早期串口输出可以放在start_kernel里面的任何位置？

非常好的文章，赞一个

@andreaji：这里的回复不能画图，所以我在http://www.wowotech.net/forum/viewtopic.php?pid=448#p448回复了你，请参考。

@fomalhaut：多谢指正

PFN(page frame number)，而不是FPN?

只要struct posix_clock包括了cdev成员，struct posix_clock_operations中的owner以及struct posix_clock中的kref应该没有存在的必要了。 ===================================================================================== 您好 linuxer，请教一个问题： 我在读 linux-3.19.y 版本的 driver/ptp/ptp_clock.c 时看到使用 ptp clock 模块使用 posix_clock_register 注册 posix clock 时 posix_clock_operations 结构体 ptp_clock_ops 的 owner 设置为 THIS_MODULE（我理解这个 THIS_MODULE 为 ptp clock 模块） static struct posix_clock_operations ptp_clock_ops = { .owner = THIS_MODULE, ... ... }; 进入 posix_clock_register 函数时将 posix_clock -> cdev.owner 也设置为 ptp_clock_ops.owner int posix_clock_register(struct posix_clock *clk, dev_t devid) { ... ... cdev_init(&clk->cdev, &posix_clock_file_operations); clk->cdev.owner = clk->ops.owner; ... ... } 可是在 posix-clock.c 中 file_operations 结构体 posix_clock_file_operations（也就是上面 cdev_init 函数中传入的 file_operations 结构体）的 owner 被设置为 THIS_MODULE，这个 THIS_MODULE 指的是什么？如果指的是 posix-clock 的话，会不会又矛盾？ 请教一下 linuxer 对于这样的设计，您是怎么看？

@lucky：最后一步unmask interrupt controller 这个是在中断处理程序执行完由硬件操作寄存器来进行操作的吗？ －－－－－－－－－－－ 这里说的mask或者ack某个IRQ number的操作是通过操作中断控制器（例如GIC）的寄存器来完成的。 既然流程第一步已经进行了执行了mask，为什么rcu_irq_exit 还会进行关闭中断的操作啊？硬中断处理中关闭中断的操作是硬件实现的？ －－－－－－－－－－－－－－－ rcu_irq_exit中的中断操作是成对的，分别是local_irq_save和local_irq_restore，都是操作的CPU中断，而mask操作是disable某个外设的IRQ，操作的是中断控制器，是不一样的。 综上所述的情况，我们说softirq和tasklet运行在中断上下文是不是有些不恰当？ －－－－－－－－－－－－－－ 这是一个见仁见智的问题，不同的人对中断上下文理解不同，我对中断上下文的理解就是当前执行那一点的current thread和当前执行路径是没有任何的关系 关于第三个问题，你的描述是正确的。

@lucky：的确，我之前在回复某个网友的提问的时候说到：挂入到multi thread或者说per cpu workqueue上的指定的work，其callback是不会在一个cpu上并发执行（也就是说在多个cpu上可以并发执行）。不过这句话是有条件限制的，当时，我的描述是针对旧的workqueue上的并发（参考的是linux2.6.23的workqueue代码）。 对于新的内核，例如4.4.6的内核，不论是bound（per cpu）或者unbounded workqueue，其work的处理都遵守下面的处理原则：在给定的时间点，同一个work只能被系统中的一个worker线程处理，也就是说，任何的work都是non-reentrant的。

@lucifer：->是指针，例如struct device *p;p->name; .是变量，例如struct device aa; aa.name;

@unicornx：文章开头一般都写了:-)