A. 在linux中，消息與信號的異同點
相同點：
消息和信號的運用都可以為任務事件驅動
不同點：
1、信號只能是回固定的幾個（如答SIGINT），且接收對象只能是進程。而消息的對象可以是進程，也可以為線程。
2、信號不需要創建，系統是識別的，用kill -l 可以查看完整的信號列表，沒有大小的討論。消息需要申請消息隊列資源，返回的是消息隊列的句柄，打進的消息體長度、消息的數量、消息隊列總的容量只受系統消息隊列配置大小的限制。
3、消息在linux系統中，由用戶層進入內核層隊列，全為復制操作，代價是4次拷貝。信號也需要調用系統調用，但信號本身成本低。
4、另外信號的使用會使阻塞的進程被中斷掉。而消息沒有這個功能。
B. 《Linux設備驅動程序》（十六）-中斷處理
設備與處理器之間的工作通常來說是非同步，設備數據要傳遞給處理器通常來說有以下幾種方法：輪詢、等待和中斷。
讓CPU進行輪詢等待總是不能讓人滿意，所以通常都採用中斷的形式，讓設備來通知CPU讀取數據。
2.6內核的函數參數與現在的參數有所區別，這里都主要介紹概念，具體實現方法需要結合具體的內核版本。
request_irq函數申請中斷，返回0表示申請成功，其他返回值表示申請失敗，其具體參數解釋如下：
flags 掩碼可以使用以下幾個：
快速和慢速處理常式 ：現代內核中基本沒有這兩個概念了，使用SA_INTERRUPT位後，當中斷被執行時，當前處理器的其他中斷都將被禁止。通常不要使用SA_INTERRUPT標志位，除非自己明確知道會發生什麼。
共享中斷 ：使用共享中斷時，一方面要使用SA_SHIRQ位，另一個是request_irq中的dev_id必須是唯一的，不能為NULL。這個限制的原因是：內核為每個中斷維護了一個共享處理常式的列表，常式中的dev_id各不相同，就像設備簽名。如果dev_id相同，在卸載的時候引起混淆（卸載了另一個中斷），當中斷到達時會產生內核OOP消息。
共享中斷需要滿足以下一個條件才能申請成功：
當不需要使用該中斷時，需要使用free_irq釋放中斷。
通常我們會在模塊載入的時候申請安裝中斷處理常式，但書中建議：在設備第一次打開的時候安裝，在設備最後一次關閉的時候卸載。
如果要查看中斷觸發的次數，可以查看 /proc/interrupts 和 /proc/stat。
書中講述了如何自動檢測中斷號，在嵌入式開發中通常都是查看原理圖和datasheet來直接確定。
自動檢測的原理如下：驅動程序通知設備產生中斷，然後查看哪些中斷信號線被觸發了。Linux提供了以下方法來進行探測：
探測工作耗時較長，建議在模塊載入的時候做。
中斷處理函數和普通函數其實差不多，唯一的區別是其運行的中斷上下文中，在這個上下文中有以下注意事項：
中斷處理函數典型用法如下：
中斷處理函數的參數和返回值含義如下：
返回值主要有兩個：IRQ_NONE和IRQ_HANDLED。
對於中斷我們是可以進行開啟和關閉的，Linux中提供了以下函數操作單個中斷的開關：
該方法可以在所有處理器上禁止或啟用中斷。
需要注意的是：
如果要關閉當前處理器上所有的中斷，則可以調用以下方法：
local_irq_save 會將中斷狀態保持到flags中，然後禁用處理器上的中斷；如果明確知道中斷沒有在其他地方被禁用，則可以使用local_irq_disable，否則請使用local_irq_save。
locat_irq_restore 會根據上面獲取到flags來恢復中斷；local_irq_enable 會無條件打開所有中斷。
在中斷中需要做一些工作，如果工作內容太多，必然導致中斷處理所需的時間過長；而中斷處理又要求能夠盡快完成，這樣才不會影響正常的系統調度，這兩個之間就產生了矛盾。
現在很多操作系統將中斷分為兩個部分來處理上面的矛盾：頂半部和底半部。
頂半部就是我們用request_irq來注冊的中斷處理函數，這個函數要求能夠盡快結束，同時在其中調度底半部，讓底半部在之後來進行後續的耗時工作。
頂半部就不再說明了，就是上面的中斷處理函數，只是要求能夠盡快處理完成並返回，不要處理耗時工作。
底半部通常使用tasklet或者工作隊列來實現。
tasklet的特點和注意事項：
工作隊列的特點和注意事項：