在做完內核裁剪後，等待編譯結果的過程是一種怎樣的體驗？

12-30

有一次開會，會議的演講非常的Boring，我混混欲睡，轉頭看見旁邊的人在用Mutt寫郵件，落款是-Greg KH，一下子精神起來。然後我就在那裡看了半個小時看大神是怎麼處理每天那麼多的Patch Submit的。

其實Greg的處理郵件模型和我們是很像的：

首先在mutt中tab找新郵件，看到patch，有可見問題就回復，沒有就保存到一個mbox中，用screen切換到另一個窗口，am，make -j (基本上都是只有一個字母的腳本，但從輸出就知道他在幹啥了）

切換回來，接著看下一個PatchSet，有些是討論的，立即回復。回復的時候幾乎沒有客套，有話說話。他的處理過程給我一個強烈的感覺，就是如果你再多說兩句不入正題的話，Greg就該把你的郵件刪除了

生成下一個mbox，回去看看編譯完了沒有（我很懷疑他用了遠程服務來編譯，因為完成得特快（當然，中間編譯本來就快，但快到這個地步，完全不像他那個Chromebook可以做到的），然後立即切換回來答覆，apply下一個patch set，接著編譯

如果前一個patch過了，再切換一個窗口（都是screen窗口），apply到下一個分支上，在那個分支上接著驗證試驗。

所以，你說等待編譯結果的過程是什麼體驗，那就是「沒有時間來體驗」：）

這個問題問的 excited!

等我開下 VMWare 來 build 個 debian 內核出來。

10:16:41 EDT 開始 build，CONCURRENCY_LEVEL=16, VMWare Workstation 最大只能支持到16個核心

去吃早飯

10:31:28 EDT build 完了，一共將近十五分鐘，刷了會知乎，還沒去吃早飯。偷懶沒裁剪內核也沒 patch，直接拿 repo 裡面 3.16.7 的 source 來 build 的

體驗就是——沒有什麼體驗。build 期間幹啥都行，反正不缺 cores.

Hint: 用 tmpfs 的話可以讓你嘗到幸福的滋味

終於知道自己的電腦渣了

這個問題還不如問等待buildroot整個編譯完是啥體驗，自從我開始玩buildroot，我都覺得make linux是挺快的步驟了

公司有兩台伺服器專門用來編譯（公司窮，不能每人一台），make -j 48 bzImage 大概30s就可以，沒試過tmpfs或ccache。

終於可以歇會了。

不應該拿到Demo後先預編譯，然後裁完再編譯，幾乎不用等，最後完成重新編譯，沒什麼感覺

make -j64

make -j16

現在電腦編譯內核也就十多分鐘吧。第二次編譯更是不需要等。

加 -j 參數後就沒什麼了