linux软件中tasklet机制.docVIP

linux软件中断——tasklet机制?? 本节我们先来说一下为什么要引入软件中断？ 一般来说，一次中断服务的过程通常可以分为两个部分。开头的 部分往往必须在关中断的条件下执行，这样才能在不受干扰的条件下“原子”地完成一些关键性操作，同时这部分操作的时间性又往往很强，必须在中断请求发生后立即或至少在一定时间限制中执行，而且相继的多次中断请求也不能合并在一起来处理。而后半部分，通常可以而且应该在开中断的条件下执行，这样才不至于因中断关闭过久而造成其他中断的丢失，同时，这些操作常常允许延时到稍后才来执行，而且有可能多次中断的相关部分合并在一起处理。这些不同的性质常常使中断服务的前后两半明显地区分开来，可以而且应该分别加以不同的实现。这里的后半部分就称为bottom half，在内核代码中往往写成bf?，而bf的这部分就可以通过软件中断来实现。因为软件中断的激活是通过代码来实现的，而不是硬件，所以就可以自己或由系统来决定激活的时机！ 那么软件中断具体在什么时候激活呢？ 我们一般认为有两个时机： 第一个时机：do_IRQ完成后，在退出的时候调用irq_exit do_IRQ ? ? ??irq_exit(); ? ? ? ? ? ??if (!in_interrupt() local_softirq_pending())//如果不处在中断上下文并且软件中断开启的话，就激活软件中断 ? ? ? ? ? ? ? ? ?invoke_softirq(); ? ? ? ? ? ? ? ? ? ? ??do_softirq(); ? ? ? ? ? ? ? ? ? ? ? ? ? ??__do_softirq(); ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?h = softirq_vec; ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?h-action(h); 第一个时机一般可以处理大部分的软件中断，但是如果软件中断过多的话，不能在这个时机完成，那么别担心，还有第二个时机！第二处：如果在irq_exit中没有完成软件中断的话，会调用后台守护进程ksoftirqd 我们得先看一看守护进程的创建： early_initcall(spawn_ksoftirqd); spawn_ksoftirqd ? ? ??cpu_callback(cpu_nfb, CPU_ONLINE, cpu); ? ? ? ? ? ? ? p = kthread_create_on_node(run_ksoftirqd, hcpu,cpu_to_node(hotcpu), ksoftirqd/%d, hotcpu); 这里创建了内核线程?run_ksoftirqd? 我们看看调用内核线程，我们看看如何激活呢？ raise_softirq ? ? ??raise_softirq_irqoff(nr); ? ? ? ? ? ? ?wakeup_softirqd();? ? ? ? ? ? ? ? ? ??struct task_struct *tsk = __this_cpu_read(ksoftirqd); ? ? ? ? ? ? ? ? ? ??wake_up_process(tsk); 我们看看这个线程做了什么： run_ksoftirqd? ? ? ?__do_softirq(); ? ? ? ? ? ?h-action(h);//果然 当然还有网卡驱动用到的软件中断，我们先不说！ 以上所谓的调度时机，实际上并不是软中断必须的，而是内核中基于软中断的tasklet机制所实现的！软中断说白了就是先写一个函数，然后在我们想执行这个函数的时候去激活它，我们完全可以自己来规划其激活时机！但是事实上，软件的开发人员并不建议我们自己注册新的软件中断，内核为我们搭建了一个使用软件中断的框架，这就是tasklet机制，而tasklet机制正是为了实现中断的下半部！ 那么要使用这个机制我们需要做些什么呢？ 1、创建 DECLARE_TASKLET(name, func, data) 我们可以看看其定义： #define DECLARE_TASKLET(name, func, data)? struct tasklet_struct name = { NULL, 0, ATOMIC_INIT(0), func, data } 由此我们也可以看出，我们也能直接这样定义： struct tasklet_struct name = { NULL, 0, ATOMIC_INIT(0), func, data } 同时我们还得构造func，这就是然间中断的执行函数！ 2、初始化： void tasklet_init(struct tasklet_str