deploy: d249317c8753b84202d09209c11ea3a48013f5e0

index.html

@@ -18,7 +18,7 @@
 
 <h2 class='titleHead'>The Linux Kernel Module Programming Guide</h2>
 <div class='author'><span class='ecrm-1200'>Peter Jay Salzman, Michael Burian, Ori Pomerantz, Bob Mottram, Jim Huang</span></div><br />
-<div class='date'><span class='ecrm-1200'>December 9, 2022</span></div>
+<div class='date'><span class='ecrm-1200'>December 11, 2022</span></div>
                                                                   
 
                                                                   
@@ -4956,13 +4956,13 @@ naming for <span class='ecti-1000'>Bottom Halves</span>) statistically book-keep
 </p><!-- l. 1844 --><p class='indent'>   The way to implement this is to call
 <code> <span class='ectt-1000'>request_irq()</span>
 </code> to get your interrupt handler called when the relevant IRQ is received.
-</p><!-- l. 1846 --><p class='indent'>   In practice IRQ handling can be a bit more complex. Hardware is often
-designed in a way that chains two interrupt controllers, so that all the IRQs
-from interrupt controller B are cascaded to a certain IRQ from interrupt
-controller A. Of course, that requires that the kernel finds out which IRQ it
-really was afterwards and that adds overhead. Other architectures offer some
-special, very low overhead, so called "fast IRQ" or FIQs. To take advantage of
-them requires handlers to be written in assembler, so they do not really
+</p><!-- l. 1846 --><p class='indent'>   In practice IRQ handling can be a bit more complex. Hardware is often designed
+in a way that chains two interrupt controllers, so that all the IRQs from
+interrupt controller B are cascaded to a certain IRQ from interrupt controller A.
+Of course, that requires that the kernel finds out which IRQ it really was
+afterwards and that adds overhead. Other architectures offer some special,
+very low overhead, so called "fast IRQ" or FIQs. To take advantage of them
+requires handlers to be written in assembly language, so they do not really
 fit into the kernel. They can be made to work similar to the others, but
 after that procedure, they are no longer any faster than "common" IRQs.
 SMP enabled kernels running on systems with more than one processor

lkmpg-for-ht.html

@@ -18,7 +18,7 @@
 
 <h2 class='titleHead'>The Linux Kernel Module Programming Guide</h2>
 <div class='author'><span class='ecrm-1200'>Peter Jay Salzman, Michael Burian, Ori Pomerantz, Bob Mottram, Jim Huang</span></div><br />
-<div class='date'><span class='ecrm-1200'>December 9, 2022</span></div>
+<div class='date'><span class='ecrm-1200'>December 11, 2022</span></div>
                                                                   
 
                                                                   
@@ -4956,13 +4956,13 @@ naming for <span class='ecti-1000'>Bottom Halves</span>) statistically book-keep
 </p><!-- l. 1844 --><p class='indent'>   The way to implement this is to call
 <code> <span class='ectt-1000'>request_irq()</span>
 </code> to get your interrupt handler called when the relevant IRQ is received.
-</p><!-- l. 1846 --><p class='indent'>   In practice IRQ handling can be a bit more complex. Hardware is often
-designed in a way that chains two interrupt controllers, so that all the IRQs
-from interrupt controller B are cascaded to a certain IRQ from interrupt
-controller A. Of course, that requires that the kernel finds out which IRQ it
-really was afterwards and that adds overhead. Other architectures offer some
-special, very low overhead, so called "fast IRQ" or FIQs. To take advantage of
-them requires handlers to be written in assembler, so they do not really
+</p><!-- l. 1846 --><p class='indent'>   In practice IRQ handling can be a bit more complex. Hardware is often designed
+in a way that chains two interrupt controllers, so that all the IRQs from
+interrupt controller B are cascaded to a certain IRQ from interrupt controller A.
+Of course, that requires that the kernel finds out which IRQ it really was
+afterwards and that adds overhead. Other architectures offer some special,
+very low overhead, so called "fast IRQ" or FIQs. To take advantage of them
+requires handlers to be written in assembly language, so they do not really
 fit into the kernel. They can be made to work similar to the others, but
 after that procedure, they are no longer any faster than "common" IRQs.
 SMP enabled kernels running on systems with more than one processor