‘壹’ linux内核在执行中断处理时是关中断的吗
1、中断处理程序与其他内核函数真正的区别在于,中断处理程序是被内核调用来相应中断的,而它们运行于中断上下文(原子上下文)中,在该上下文中执行的代码不可阻塞。中断就是由硬件打断操作系统。
2、异常与中断不同,它在产生时必须考虑与处理器时钟同步。异常被称为同步中断,例如:除0、缺页异常、陷入内核(trap)引起系统调用处理程序异常。
3、不同的设备对应的中断不同,而每个中断都通过一个唯一的数字(中断号)标识。
4、既想让中断处理程序运行得快,又想中断处理程序完成的工作量多,为了在这两个相悖的目标之间达到一种平衡,一般把中断处理分为两个部分。中断处理程序是上半部(top half):接收到一个中断,它就立刻开始执行,但只做有严格时限的工作,例如对接受的中断进行应答或者复位硬件,这些工作都是在中断被禁止的情况下完成的(上半部情况下,中断被禁止);另一部分是下半部(bottom half):能够被允许稍后完成的工作会推迟到下半部。
‘贰’ linux里面的关中断是什么意思
就是对中断进行屏蔽,使得系统不再响应中断。
当然,有些中断(尤其是硬件中断)是不可屏蔽的。
‘叁’ LINUX软中断通信
我也是初学者,这里抄一段《Linux设备驱动程序》书上的给你:
Linux的中断宏观分为两种:软中断和硬中断。声明一下,这里的软和硬的意思是指和软件相关以及和硬件相关,而不是软件实现的中断或硬件实现的中断。软中断就是“信号机制”。软中断不是软件中断。Linux通过信号来产生对进程的各种中断操作,我们现在知道的信号共有31个,其具体内容这里略过。
一般来说,软中断是由内核机制的触发事件引起的(例如进程运行超时),但是不可忽视有大量的软中断也是由于和硬件有关的中断引起的,例如当打印机端口产生一个硬件中断时,会通知和硬件相关的硬中断,硬中断就会产生一个软中断并送到操作系统内核里,这样内核就会根据这个软中断唤醒睡眠在打印机任务队列中的处理进程。
硬中断就是通常意义上的“中断处理程序”,它是直接处理由硬件发过来的中断信号的。当硬中断收到它应当处理的中断信号以后,就回去自己驱动的设备上去看看设备的状态寄存器以了解发生了什么事情,并进行相应的操作。
对于软中断,我们不做讨论,那是进程调度里要考虑的事情。由于我们讨论的是设备驱动程序的中断问题,所以焦点集中在硬中断里。我们这里讨论的是硬中断,即和硬件相关的中断。
要中断,是因为外设需要通知操作系统她那里发生了一些事情,但是中断的功能仅仅是一个设备报警灯,当灯亮的时候中断处理程序只知道有事情发生了,但发生了什么事情还要亲自到设备那里去看才行。也就是说,当中断处理程序得知设备发生了一个中断的时候,它并不知道设备发生了什么事情,只有当它访问了设备上的一些状态寄存器以后,才能知道具体发生了什么,要怎么去处理。
设备通过中断线向中断控制器发送高电平告诉操作系统它产生了一个中断,而操作系统会从中断控制器的状态位知道是哪条中断线上产生了中断。PC机上使用的中断控制器是8259,这种控制器每一个可以管理8条中断线,当两个8259级联的时候共可以控制15条中断线。这里的中断线是实实在在的电路,他们通过硬件接口连接到CPU外的设备控制器上。
并不是每个设备都可以向中断线上发中断信号的,只有对某一条确定的中断线勇有了控制权,才可以向这条中断线上发送信号。由于计算机的外部设备越来越多,所以15条中断线已经不够用了,中断线是非常宝贵的资源。要使用中断线,就得进行中断线的申请,就是IRQ(Interrupt Requirement),我们也常把申请一条中断线成为申请一个IRQ或者是申请一个中断号。
IRQ是非常宝贵的,所以我们建议只有当设备需要中断的时候才申请占用一个IRQ,或者是在申请IRQ时采用共享中断的方式,这样可以让更多的设备使用中断。无论对IRQ的使用方式是独占还是共享,申请IRQ的过程都是一样的,分为3步:
1.将所有的中断线探测一遍,看看哪些中断还没有被占用。从这些还没有被占用的中断中选一个作为该设备的IRQ。
2.通过中断申请函数申请选定的IRQ,这是要指定申请的方式是独占还是共享。
3.根据中断申请函数的返回值决定怎么做:如果成功了万事大吉,如果没成功则或者重新申请或者放弃申请并返回错误。
Linux中的中断处理程序很有特色,它的一个中断处理程序分为两个部分:上半部(top half)和下半部(bottom half)。之所以会有上半部和下半部之分,完全是考虑到中断处理的效率。
上半部的功能是“登记中断”。当一个中断发生时,他就把设备驱动程序中中断例程的下半部挂到该设备的下半部执行队列中去,然后就没事情了--等待新的中断的到来。这样一来,上半部执行的速度就会很快,他就可以接受更多她负责的设备产生的中断了。上半部之所以要快,是因为它是完全屏蔽中断的,如果她不执行完,其它的中断就不能被及时的处理,只能等到这个中断处理程序执行完毕以后。所以,要尽可能多得对设备产生的中断进行服务和处理,中断处理程序就一定要快。
但是,有些中断事件的处理是比较复杂的,所以中断处理程序必须多花一点时间才能够把事情做完。可怎么样化解在短时间内完成复杂处理的矛盾呢,这时候 Linux引入了下半部的概念。下半部和上半部最大的不同是下半部是可中断的,而上半部是不可中断的。下半部几乎做了中断处理程序所有的事情,因为上半部只是将下半部排到了他们所负责的设备的中断处理队列中去,然后就什么都不管了。下半部一般所负责的工作是察看设备以获得产生中断的事件信息,并根据这些信息(一般通过读设备上的寄存器得来)进行相应的处理。如果有些时间下半部不知道怎么去做,他就使用着名的鸵鸟算法来解决问题--说白了就是忽略这个事件。
由于下半部是可中断的,所以在它运行期间,如果其它的设备产生了中断,这个下半部可以暂时的中断掉,等到那个设备的上半部运行完了,再回头来运行它。但是有一点一定要注意,那就是如果一个设备中断处理程序正在运行,无论她是运行上半部还是运行下半部,只要中断处理程序还没有处理完毕,在这期间设备产生的新的中断都将被忽略掉。因为中断处理程序是不可重入的,同一个中断处理程序是不能并行的。
在Linux Kernel 2.0以前,中断分为快中断和慢中断(伪中断我们这里不谈),其中快中断的下半部也是不可中断的,这样可以保证它执行的快一点。但是由于现在硬件水平不断上升,快中断和慢中断的运行速度已经没有什么差别了,所以为了提高中断例程事务处理的效率,从Linux kernel 2.0以后,中断处理程序全部都是慢中断的形式了--他们的下半部是可以被中断的。
但是,在下半部中,你也可以进行中断屏蔽--如果某一段代码不能被中断的话。你可以使用cti、sti或者是save_flag、restore_flag来实现你的想法。
在处理中断的时候,中断控制器会屏蔽掉原先发送中断的那个设备,直到她发送的上一个中断被处理完了为止。因此如果发送中断的那个设备载中断处理期间又发送了一个中断,那么这个中断就被永远的丢失了。
之所以发生这种事情,是因为中断控制器并不能缓冲中断信息,所以当前一个中断没有处理完以前又有新的中断到达,他肯定会丢掉新的中断的。但是这种缺陷可以通过设置主处理器(CPU)上的“置中断标志位”(sti)来解决,因为主处理器具有缓冲中断的功能。如果使用了“置中断标志位”,那么在处理完中断以后使用sti函数就可以使先前被屏蔽的中断得到服务。
有时候需要屏蔽中断,可是为什么要将这个中断屏蔽掉呢?这并不是因为技术上实现不了同一中断例程的并行,而是出于管理上的考虑。之所以在中断处理的过程中要屏蔽同一IRQ来的新中断,是因为中断处理程序是不可重入的,所以不能并行执行同一个中断处理程序。在这里我们举一个例子,从这里子例中可以看出如果一个中断处理程序是可以并行的话,那么很有可能会发生驱动程序锁死的情况。当驱动程序锁死的时候,你的操作系统并不一定会崩溃,但是锁死的驱动程序所支持的那个设备是不能再使用了--设备驱动程序死了,设备也就死了。
A是一段代码,B是操作设备寄存器R1的代码,C是操作设备寄存器R2的代码。其中激发PS1的事件会使A1产生一个中断,然后B1去读R1中已有的数据,然后代码C1向R2中写数据。而激发PS2的事件会使A2产生一个中断,然后B2删除R1中的数据,然后C2读去R2中的数据。
如果PS1先产生,且当他执行到A1和B1之间的时候,如果PS2产生了,这是A2会产生一个中断,将PS2中断掉(挂到任务队列的尾部),然后删除了 R1的内容。当PS2运行到C2时,由于C1还没有向R2中写数据,所以C2将会在这里被挂起,PS2就睡眠在代码C2上,直到有数据可读的时候被信号唤醒。这是由于PS1中的B2原先要读的R1中的数据被PS2中的B2删除了,所以PS1页会睡眠在B1上,直到有数据可读的时候被信号唤醒。这样一来,唤醒PS1和PS2的事件就永远不会发生了,因此PS1和PS2之间就锁死了。
由于设备驱动程序要和设备的寄存器打交道,所以很难写出可以重入的代码来,因为设备寄存器就是全局变量。因此,最简洁的办法就是禁止同一设备的中断处理程序并行,即设备的中断处理程序是不可重入的。
有一点一定要清楚:在2.0版本以后的Linux kernel中,所有的上半部都是不可中断的(上半部的操作是原子性的);不同设备的下半部可以互相中断,但一个特定的下半部不能被它自己所中断(即同一个下半部不能并)。
由于中断处理程序要求不可重入,所以程序员也不必为编写可重入的代码而头痛了。编写可重入的设备驱动程序是可以的,编写可重入的中断处理程序是非常难得,几乎不可能。
我们都知道,一旦竞争条件出现了,就有可能会发生死锁的情况,严重时可能会将整个系统锁死。所以一定要避免竞争条件的出现。只要注意一点:绝大多数由于中断产生的竞争条件,都是在带有中断的
内核进程被睡眠造成的。所以在实现中断的时候,一定要相信谨慎的让进程睡眠,必要的时候可以使用cli、sti或者save_flag、restore_flag。
‘肆’ Linux几种中断信号的区别:HUP,INT,KILL,TERM,TSTP
Linux的HUP,INT,KILL,TERM,TSTP中断信号区别为:键入不同、对应操作不同、启用不同。
一、键入不同
1、HUP中断信号:HUP中断信号是当用户键入<Ctrl+X>时由终端驱动程序发送的信号。
2、INT中断信号:INT中断信号是当用户键入<Ctrl+I>时由终端驱动程序发送的信号。
3、KILL中断信号:KILL中断信号是当用户键入<Ctrl+Z>时由终端驱动程序发送的信号。
4、TERM中断信号:TERM中断信号是当用户键入<Ctrl+>时由终端驱动程序发送的信号。
5、TSTP中断信号:TSTP中断信号是当用户键入<Ctrl+T>时由终端驱动程序发送的信号。二、对应操作不同
1、HUP中断信号:HUP中断信号的对应操作为让进程挂起,睡眠。
2、INT中断信号:INT中断信号的对应操作为正常关闭所有进程。
3、KILL中断信号:KILL中断信号的对应操作为强制关闭所有进程。
4、TERM中断信号:TERM中断信号的对应操作为正常的退出进程。
5、TSTP中断信号:TSTP中断信号的对应操作为暂时停用进程。
三、启用不同
1、HUP中断信号:HUP中断信号发送后,可以重新被用户再次输入恢复启用进程。
2、INT中断信号:INT中断信号发送后,不可以重新被用户再次输入恢复启用进程。
3、KILL中断信号:KILL中断信号发送后,不可以重新被用户再次输入恢复启用进程。
4、TERM中断信号:TERM中断信号发送后,可以重新被用户再次输入启用进程。
5、TSTP中断信号:TSTP中断信号发送后,可以重新被用户再次输入继续使用进程。
‘伍’ linux中断响应大概是多长时间
一、中断处理为什么要下半部? Linux在中断处理中间中断处理分了上半部和下半部,目的就是提高系统的响应能力和并发能力。通俗一点来讲:当一个中断产生,调用该中断对应的处理程序(上半部)然后告诉系统,对应的后半部可以执行了。然后中断处理程序就返回,下半部会在合适的时机有系统调用。这样一来就大大的减少了中断处理所需要的时间。 二、那些工作应该放在上半部,那些应该放在下半部? 没有严格的规则,只有一些提示: 1、对时间非常敏感,放在上半部。 2、与硬件相关的,放在上半部。 3、不能被其他中断打断的工作,放在上半部。 以上三点之外的,考虑放在下半部。 三、下半部机制在Linux中是怎么实现的? 下半部在Linux中有以下实现机制: 1、BH(在2.5中删除) 2、任务队列(task queue,在2.5删除) 3、软中断(softirq,2.3开始。本文重点) 4、tasklet(2.3开始) 5、工作队列(work queue,2.5开始) 四、软中断是怎么实现的(以下代码出自2.6.32)? 软中断不会抢占另外一个软中断,唯一可以抢占软中断的是中断处理程序。 软中断可以在不同CPU上并发执行(哪怕是同一个软中断) 1、软中断是编译期间静态分配的,定义如下: struct softirq_action { void (*action)(struct softirq_action *); }; /* * PLEASE, avoid to allocate new softirqs, if you need not _really_ high * frequency threaded job scheling. For almost all the purposes * tasklets are more than enough. F.e. all serial device BHs et * al. should be converted to tasklets, not to softirqs. */ enum { HI_SOFTIRQ=0, TIMER_SOFTIRQ, NET_TX_SOFTIRQ, NET_RX_SOFTIRQ, BLOCK_SOFTIRQ, BLOCK_IOPOLL_SOFTIRQ, TASKLET_SOFTIRQ, SCHED_SOFTIRQ, HRTIMER_SOFTIRQ, RCU_SOFTIRQ, /* Preferable RCU should always be the last softirq */ NR_SOFTIRQS }; /* * map softirq index to softirq name. update 'softirq_to_name' in * kernel/softirq.c when adding a new softirq. */ extern char *softirq_to_name[NR_SOFTIRQS]; static struct softirq_action softirq_vec[NR_SOFTIRQS] __cacheline_aligned_in_smp; 说明: (1)、软中断的个数书上说是32,看来到这个版本已经发生变化了。 (2)、void (*action)(struct softirq_action *);传递整个结构体指针在于当结构体成员发生变化是,接口不变。 2、系统执行软中断一个注册的软中断必须被标记后才会执行(触发软中断),通常中断处理程序会在返回前标记它的软中断。在下列地方,待处理的软中断会被执行: (1)、从一个硬件中断代码处返回。 (2)、在ksoftirqd内核线程。 (3)、在那些显示检查和执行待处理的软中断代码中。 ksoftirqd说明: 每个处理器都有一个这样的线程。所有线程的名字都叫做ksoftirq/n,区别在于n,它对应的是处理器的编号。在一个双CPU的机器上就有两个这样的线程,分别叫做ksoftirqd/0和ksoftirqd/1。为了保证只要有空闲的处理器,它们就会处理软中断,所以给每个处理器都分配一个这样的线程。 执行软中断的代码如下: asmlinkage void __do_softirq(void) { struct softirq_action *h; __u32 pending; int max_restart = MAX_SOFTIRQ_RESTART; int cpu; pending = local_softirq_pending(); account_system_vtime(current); __local_bh_disable((unsigned long)__builtin_return_address(0)); lockdep_softirq_enter(); cpu = smp_processor_id(); restart: /* Reset the pending bitmask before enabling irqs */ set_softirq_pending(0); local_irq_enable(); h = softirq_vec; do { if (pending & 1) { int prev_count = preempt_count(); kstat_incr_softirqs_this_cpu(h - softirq_vec); trace_softirq_entry(h, softirq_vec); h->action(h); trace_softirq_exit(h, softirq_vec); if (unlikely(prev_count != preempt_count())) { printk(KERN_ERR "huh, entered softirq %td %s %p" "with preempt_count %08x," " exited with %08x?\n", h - softirq_vec, softirq_to_name[h - softirq_vec], h->action, prev_count, preempt_count()); preempt_count() = prev_count; } rcu_bh_qs(cpu); } h++; pending >>= 1; } while (pending); local_irq_disable(); pending = local_softirq_pending(); if (pending && --max_restart) goto restart; if (pending) wakeup_softirqd(); lockdep_softirq_exit(); account_system_vtime(current); _local_bh_enable(); } 3、编写自己的软中断 (1)、分配索引,在HI_SOFTIRQ与NR_SOFTIRQS中间添加自己的索引号。 (2)、注册处理程序,处理程序:open_softirq(索引号,处理函数)。 (3)、触发你的软中断:raise_softirq(索引号)。 4、软中断处理程序注意 (1)、软中断处理程序执行的时候,允许响应中断,但自己不能休眠。 (2)、如果软中断在执行的时候再次触发,则别的处理器可以同时执行,所以加锁很关键。
‘陆’ Linux中断 异常 系统调用 中断上半部 中断下半部 这些有什么区别和联系
中断分软中断跟硬中断,硬中断是由硬件从外部触发,软中断由软件触发,就像linux系统调用int 80一样。至于中断的上下部其实就是因为中断的处理时间跟它的优先级不一定成正比,所以一般先处理中断最重要的部分(上半部),待到不怎么忙的时候,再来处理比较悠闲的部分(下半部)。就像输入的时候,拿到键盘输入的是什么才是最重要的(上半部),显示字符才是次要的(下半部)。
‘柒’ Linux 系统中的中断是不是没有中断优先级
关于中断嵌套:在linux内核里,如果驱动在申请注册中断的时候没有特别的指定,do_irq在做中断响应的时候,是开启中断的,如果在驱动的中断处理函数正在执行的过程中,出现同一设备的中断或者不同设备的中断,这时候新的中断会被立即处理,还是被pending,等当前中断处理完成后,再做处理。在2.4和2.6内核里,关于这一块是否有什么不同。 一般申请中断的时候都允许开中断,即不使用SA_INTERRUPT标志。如果允许共享则加上 SA_SHIRQ,如果可以为内核熵池提供熵值(譬如你写的驱动是ide之类的驱动),则再加上 SA_SAMPLE_RANDOM标志。这是普通的中断请求过程。对于这种一般情况,只要发生中断,就可以抢占内核,即使内核正在执行其他中断函数。这里有两点说明:一是因为linux不支持 中断优先级,因此任何中断都可以抢占其他中断,但是同种类型的中断(即定义使用同一个 中断线的中断)不会发生抢占,他们会在执行本类型中断的时候依次被调用执行。二是所谓 只要发生中断,就可以抢占内核这句是有一定限制的,因为当中断发生的时候系统由中断门 进入时自动关中断(对于x86平台就是将eflags寄存器的if位置为0),只有当中断函数被执行 (handle_IRQ_event)的过程中开中断之后才能有抢占。 对于同种类型的中断,由于其使用同样的idt表项,通过其状态标志(IRQ_PENDING和 IRQ_INPROGRESS)可以防止同种类型的中断函数执行(注意:是防止handle_IRQ_event被重入, 而不是防止do_IRQ函数被重入),对于不同的中断,则可以自由的嵌套。因此,所谓中断嵌套, 对于不同的中断是可以自由嵌套的,而对于同种类型的中断,是不可以嵌套执行的。以下简单解释一下如何利用状态标志来防止同种类型中断的重入:当某种类型的中断第一次发生时,首先其idt表项的状态位上被赋予IRQ_PENDING标志,表示有待处理。 然后将中断处理函数action置为null,然后由于其状态没有IRQ_INPROGRESS标志(第一次),故将其状态置上IRQ_INPROGRESS并去处IRQ_PENDING标志,同时将action赋予相应的中断处理函数指针(这里是一个重点,linux很巧妙的用法,随后说明)。这样,后面就可以顺利执行handle_IRQ_event进行中断处理,当在handle_IRQ_event中开中断后,如果有同种类型的中断发生,则再次进入do_IRQ函数,然后其状态位上加上IRQ_PENDING标志,但是由于前一次中断处理中加上的IRQ_INPROGRESS没有被清除,因此这里无法清除IRQ_PENDING标志,因此action还是为null,这样就无法再次执行handle_IRQ_event函数。从而退出本次中断处理,返回上一次的中断处理函数中,即继续执行handle_IRQ_event函数。当handle_IRQ_event返回时检查IRQ_PENDING标志,发现存在这个标志,说明handle_IRQ_event执行过程中被中断过,存在未处理的同类中断,因此再次循环执行handle_IRQ_event函数。直到不存在IRQ_PENDING标志为止。2.4和2.6的差别,就我来看,主要是在2.6中一进入do_IRQ,多了一个关闭内核抢占的动作,同时在处理中多了一种对IRQ_PER_CPU类型的中断的处理,其他没有什么太大的改变。这类IRQ_PER_CPU的中断主要用在smp环境下将中断绑定在某一个指定的cpu上。例如arch/ppc/syslib/open_pic.c中的openpic_init中初始化ipi中断的时候。 其实简单的说,中断可以嵌套,但是同种类型的中断是不可以嵌套的,因为在IRQ上发生中断,在中断响应的过程中,这个IRQ是屏蔽的,也就是这个IRQ的中断是不能被发现的。 同时在内核的临界区内,中断是被禁止的 关于do_IRQ可能会丢失中断请求:do_IRQ函数是通过在执行完handle_IRQ_event函数之后判断status是否被设置了IRQ_PENDING标志来判断是否还有没有被处理的同一通道的中断请求。 但是这种方法只能判断是否有,而不能知道有多少个未处理的统一通道中断请求。也就是说,假如在第一个中断请求执行handle_IRQ_event函数的过程中来了同一通道的两个或更多中断请求,而这些中断不会再来,那么仅仅通过判断status是否设置了IRQ_PENDING标志不知道到底有多少个未处理的中断,handle_IRQ_event只会被再执行一次。这算不算是个bug呢? 不算,只要知道有中断没有处理就OK了,知道1个和知道N个,本质上都是一样的。作为外设,应当能够处理自己中断未被处理的情况。不可能丢失的,在每一个中断描述符的结构体内,都有一个链表,链表中存放着服务例程序关于中断中使用的几个重要概念和关系: 一、基本概念 1. 产生的位置 发生的时刻 时序 中断 CPU外部 随机 异步 异常 CPU正在执行的程序 一条指令终止执行后 同步 2.由中断或异常执行的代码不是一个进程,而是一个内核控制路径,代表中断发生时正在运行的进程的执行 中断处理程序与正在运行的程序无关 引起异常处理程序的进程正是异常处理程序运行时的当前进程 二、特点 (2)能以嵌套的方式执行,但是同种类型的中断不可以嵌套 (3)尽可能地限制临界区,因为在临界区中,中断被禁止 2.大部分异常发生在用户态,缺页异常是唯一发生于内核态能触发的异常 缺页异常意味着进程切换,因此中断处理程序从不执行可以导致缺页的操作 3.中断处理程序运行于内核态 中断发生于用户态时,要把进程的用户空间堆栈切换到进程的系统空间堆栈,刚切换时,内核堆栈是空的 中断发生于内核态时, 不需要堆栈空间的切换 三、分类 1.中断的分类:可屏蔽中断、不可屏蔽中断 2.异常的分类: 分类 解决异常的方法 举例 故障 那条指令会被重新执行 缺页异常处理程序 陷阱 会从下一条指令开始执行 调试程序
‘捌’ linux系统的软中断的中断事件有哪些
软中断就是信号中断,能发送信号的事件就能发送中断,比如键盘中断SIGINT,SIGTSTP,SIGSTOP, 时钟中断SIGALRM,浮点中断等等