回答編集履歴
1
update
test
CHANGED
|
@@ -9,3 +9,27 @@
|
|
|
9
9
|
|
|
10
10
|
|
|
11
11
|
POSIX仕様を定める [IEEE Std 1003.1-2017](https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03), 2.4.3 Signal Actionsには **非同期シグナルセーフ(async-signal-safe)** な関数を列挙しています。
|
|
12
|
+
|
|
13
|
+
|
|
14
|
+
|
|
15
|
+
----
|
|
16
|
+
|
|
17
|
+
|
|
18
|
+
|
|
19
|
+
> 環境はx86,OSはLinuxを前提
|
|
20
|
+
|
|
21
|
+
|
|
22
|
+
|
|
23
|
+
Linuxでのハードウェア割り込み処理は、デバイスドライバとして実現されます。
|
|
24
|
+
|
|
25
|
+
|
|
26
|
+
|
|
27
|
+
たとえば [Linux Device Drivers, 3rd Ed.](https://www.oreilly.com/library/view/linux-device-drivers/0596005903/ch10.html), Chap10. Interrupt Handling, Implementing a Handler では、下記のように説明されています。
|
|
28
|
+
|
|
29
|
+
|
|
30
|
+
|
|
31
|
+
> The only peculiarity is that a handler runs at interrupt time and, therefore, suffers some restrictions on what it can do. These restrictions are the same as those we saw with kernel timers. A handler can't transfer data to or from user space, because it doesn't execute in the context of a process. Handlers also cannot do anything that would sleep, such as calling wait_event, allocating memory with anything other than `GFP_ATOMIC`, or locking a semaphore. Finally, handlers cannot call schedule.
|
|
32
|
+
|
|
33
|
+
>
|
|
34
|
+
|
|
35
|
+
> The role of an interrupt handler is to give feedback to its device about interrupt reception and to read or write data according to the meaning of the interrupt being serviced. The first step usually consists of clearing a bit on the interface board; most hardware devices won't generate other interrupts until their "interrupt-pending" bit has been cleared. Depending on how your hardware works, this step may need to be performed last instead of first; there is no catch-all rule here. Some devices don't require this step, because they don't have an "interrupt-pending" bit; such devices are a minority, although the parallel port is one of them. For that reason, short does not have to clear such a bit.
|