死在/dev/random上

標籤：style   blog   http   color   使用   檔案   ar   問題   

FOTA差分升級的時候有個retouch_binaries操作，我這裡到了這一句就卡住了，等待的圈圈能轉幾天也不見完。後來發覺亂捅幾下居然完了。找到一個解決此問題的patch，發現是將/dev/random修改成了/dev/urandom

diff --git a/updater/install.c b/updater/install.cindex a1acdb9..2f2631a 100644--- a/updater/install.c+++ b/updater/install.c@@ -450,7 +450,7 @@ Value* RetouchBinariesFn(const char* name, State* state,     bool override_set = false;     int32_t random_base = time(NULL) % 1024;     // some more randomness from /dev/random-    FILE *f_random = fopen("/dev/random", "rb");+    FILE *f_random = fopen("/dev/urandom", "rb");     uint16_t random_bits = 0;     if (f_random != NULL) {         fread(&random_bits, 2, 1, f_random);

遇到這樣的事情，當然是先上網搜尋/dev/random和/dev/urandom，找到一段話（http://www.linuxidc.com/Linux/2012-05/60476.htm）

Linux中的隨機數可以從兩個特殊的檔案中產生，一個是/dev/urandom.另外一個是/dev/random。他們產生隨機數的原理是利用當前系統的熵池來計算出固定一定數量的隨機位元，然後將這些位元作為位元組流返回。熵池就是當前系統的環境噪音，熵指的是一個系統的混亂程度，系統噪音可以通過很多參數來評估，如記憶體的使用，檔案的使用量，不同類型的進程數量等等。如果當前環境噪音變化的不是很劇烈或者當前環境噪音很小，比如剛開機的時候，而當前需要大量的隨機位元，這時產生的隨機數的隨機效果就不是很好了。

這就是為什麼會有/dev/urandom和/dev/random這兩種不同的檔案，後者在不能產生新的隨機數時會阻塞程式，而前者不會（ublock），當然產生的隨機數效果就不太好了，這對加密解密這樣的應用來說就不是一種很好的選擇。/dev/random會阻塞當前的程式，直到根據熵池產生新的隨機位元組之後才返回，所以使用/dev/random比使用/dev/urandom產生大量隨機數的速度要慢。

好吧，上面那段熵什麼的我們就先不深究了，我下來再學習。不過基本上可以解釋我的兩個疑問了：

1. 為什麼會這麼慢？“/dev/random”就是慢啊，升級的時候，系統基本上動作很小的，拿來那麼多的變化讓它去產生隨機數？即使我嘗試在我電腦上執行“cat /dev/random|od -x”，然後什麼也不動，就等它出字元，也是龜速。
2. 為什麼捅兩下會快？不管是按鍵還是觸屏，都會導致手機系統的變化，這個變化就是產生隨機數的根源，動了就有隨機數了，數出來了，更新也就能繼續了。這也就是為什麼放這一個晚上也沒有完的原因了，放著就放著了，系統基本處於靜止狀態了。

這哪是慢啊，簡直是要命了。

引申閱讀 http://zh.wikipedia.org/wiki//dev/random