系統panic後主動廣播最後核心dmesg資訊-一個幾乎可以使用的方案

1.減少記憶體操作；

2.不處理異常流；

3.盡可能簡化，不再計算校驗值；

4.避免ARP互動，直接廣播。

代碼的邏輯如下：

1.加載子產品：預先配置設定skb和get device，為了不在panic以後處理記憶體；注冊通知鍊。

2.panic之後：調用通知鍊的通知操作，用最簡化的方式廣播沒有校驗碼的資料包。

代碼如下：

需要指出的 是kernel_log_buffer接口，這個接口是我自己添加進核心并EXPORT出來的。我認為這是必要的，printk将資訊放在了核心的一個緩 沖區中，這個緩沖區可以被使用者态程序通過syslog系統調用讀取。我們知道，正常的辦法是核心資訊被syslog守護程序讀取，然後發送到網絡或者儲存 成檔案。但是panic之後呢？既然使用者态已經完全不再運作，那麼就不存在通過什麼守護程序存日志的希望了，當然在核心panic通知鍊鈎子中直接操作磁 盤日志檔案是可以的，但是那太不可靠，因為磁盤的IO邏輯同樣存在于核心态代碼或者驅動代碼中，此時核心已經panic了...雖然從網絡發送資料也同樣 要用到已經panic的核心執行流，但是畢竟協定棧操作要比磁盤操作的調用深度要淺很多(資料的最終解釋，排序，儲存操作都在對端進行，磁盤IO則不 然)。

       不管怎麼樣，不管是磁盤操作還是網絡操作，都需要将核心log緩沖區中的記憶體dump下來才好，然而核心log緩沖區本身并沒有被EXPORT，它隻能通過不多的幾個系統調用接口來擷取，而這些接口很難在核心裡面調用，是以我自己添加了一個：

其中，buf為核心log儲存到的緩沖區，max_len為buf的長度，傳回值為實際傳回資訊的長度。這個接口完全類似于read系統調用。

本文轉自 dog250 51CTO部落格，原文連結:http://blog.51cto.com/dog250/1610430