Linux - 嵌套中断
Linux - nested interrupts
Linux是否使用嵌套中断？
我的意思是，例如，当从任何设备服务中断时，可以允许在此例程中进一步中断吗？还是涉及上半部分和下半部分？
编辑：
如果Linux使用嵌套中断，如何关心他们stack/s？
是的，Linux 中断是可重入的。 https://unix.stackexchange.com/a/7172/40346
The Linux kernel is reentrant (like all UNIX ones), which simply means that multiple processes can be executed by the CPU. He doesn't have to wait till a disk access read is handled by the deadly slow HDD controller, the CPU can process some other stuff until the disk access is finished (which itself will trigger an interrupt if so).
Generally, an interrupt can be interrupted by an other interrupt (preemption), that's called 'Nested Execution'. Depending on the architecture, there are still some critical functions which have to run without interruption (non-preemptive) by completely disabling interrupts. On x86, these are some time relevant functions (time.c, hpet.c) and some xen stuff.
There are only two priority levels concerning interrupts: 'enable all interrupts' or 'disable all interrupts', so I guess your "high priority interrupt" is the second one. This is the only behavior the Linux kernel knows concerning interrupt priorities and has nothing to do with real-time extensions.
If an interruptible interrupt (your "low priority interrupt") gets interrupted by an other interrupt ("high" or "low"), the kernel saves the old execution code of the interrupted interrupt and starts to process the new interrupt. This "nesting" can happen multiple times and thus can create multiple levels of interrupted interrupts. Afterwards, the kernel reloads the saved code from the old interrupt and tries to finish the old one.
Linux是否使用嵌套中断？
我的意思是，例如，当从任何设备服务中断时，可以允许在此例程中进一步中断吗？还是涉及上半部分和下半部分？
编辑：
如果Linux使用嵌套中断，如何关心他们stack/s？
是的，Linux 中断是可重入的。 https://unix.stackexchange.com/a/7172/40346
The Linux kernel is reentrant (like all UNIX ones), which simply means that multiple processes can be executed by the CPU. He doesn't have to wait till a disk access read is handled by the deadly slow HDD controller, the CPU can process some other stuff until the disk access is finished (which itself will trigger an interrupt if so).
Generally, an interrupt can be interrupted by an other interrupt (preemption), that's called 'Nested Execution'. Depending on the architecture, there are still some critical functions which have to run without interruption (non-preemptive) by completely disabling interrupts. On x86, these are some time relevant functions (time.c, hpet.c) and some xen stuff.
There are only two priority levels concerning interrupts: 'enable all interrupts' or 'disable all interrupts', so I guess your "high priority interrupt" is the second one. This is the only behavior the Linux kernel knows concerning interrupt priorities and has nothing to do with real-time extensions.
If an interruptible interrupt (your "low priority interrupt") gets interrupted by an other interrupt ("high" or "low"), the kernel saves the old execution code of the interrupted interrupt and starts to process the new interrupt. This "nesting" can happen multiple times and thus can create multiple levels of interrupted interrupts. Afterwards, the kernel reloads the saved code from the old interrupt and tries to finish the old one.