Linux 2.6.39-rc3的一個插曲

2011年4月12日，Linux 2.6.39-rc3發布了，Linus Torvalds寫了一個發布郵件，其中包含了一個長長的為這個版本做過貢獻的人員名單，這個名單中有很多看上去應該是中國人的名字，我挺為他們感到驕傲的（不知道你是否還記得以前本站的”Linux是由誰寫的“）。

不過，沒過一會，發現了一個bug，經過大家的調查（2.6.38版沒有發現這個問題），很快，找到了原因，是因為一個內存地址的問題，一個叫Yinghai Lu的人（看其名字應該是中國人，其郵件是@kernel.org）找到了原因—— radeon card使用了一個不正確的內存地址[0xa0000000 – 0xc000000]。Joerg Roedel跟貼說，這個地址超出了4GB的內存，然后他和Alex Deucher聊了一會，覺得不應該是這個問題，因為這個地址應該是GPU的，而不是系統內存的。

好像，Yinghai Lu沒有理會他們說的不應該是這個問題，給出了個fix：

diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
index 86d1ad4..3b6a9d5 100644
--- a/arch/x86/kernel/aperture_64.c
+++ b/arch/x86/kernel/aperture_64.c
@@ -83,7 +83,7 @@ static u32 __init allocate_aperture(void)
  * so don't use 512M below as gart iommu, leave the space for kernel
  * code for safe
  */
-addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<20);
+addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<21);
  if (addr == MEMBLOCK_ERROR || addr + aper_size > 0xffffffff) {
 printk(KERN_ERR
 "Cannot allocate aperture memory hole (%lx,%uK)\n",

看到這個fix，Linus Torvalds不高興了，他回貼問道：

• 為什么全都是Magic Numbers？

• 為什么0x80000000就那么特殊？

• 為什么我們這樣改就行？

還說了這樣一句話——

This kind of “I broke things, so now I will jiggle things randomly until they unbreak” is not acceptable. 這種“我把事搞砸了，就隨意地調整直到事情又工作”的方式是不可接受的。

還說，這里即沒有說明為什么我們fix在了正確的地方（也沒有解釋那些Magic Number是什么），也沒有回滾那個有問題的patch。還說——

Don’t just make random changes. There really are only two acceptable models of development: “think and analyze” or “years and years of testing on thousands of machines”. Those two really do work.
不要亂改。那里只有兩個可行的開發模式：“思考和分析” 或是 “數年數年地不斷地在幾千臺機器上測試”。這兩個方式才是真正可行的。

當然，Yinghai Lu對其做了解釋，說我們的確調查過了，老的代碼用的內存地址是0x80000000，新的則是用0xa0000000，而0xa0000000不工作。這又引發了 Linus Torvalds 的不滿的回貼。Linus說

Yinghai, we have had this discussion before, and dammit, you need to understand the difference between “understanding the problem” and “put in random values until it works on one machine”.
Yinghai，我們以前談過這個事，該死的，你真的需要明白“理解一個錯誤”和“設一個隨意的值直到其正常工作”的區別。
There was absolutely _zero_ analysis done. You do not actually understand WHY the numbers matter. You just look at two random numbers, and one works, the other does not. That’s not “analyzing”. That’s just “random number games”.
這里就根本沒有分析。你沒有直正的明白為什么這些數字能行。你只看了兩個隨機的數，一個能行，另一個不行。這不是“分析”，這叫“隨機數游戲”。
If you cannot see and understand the difference between an actual analytical solution where you _understand_ what the code is doing and  why, and “random numbers that happen to work on one machine”, I don’t know what to tell you.
一個解決方案真正經過分析了那段代碼干什么的為什么的，另一個是“隨機數字可以讓其在一臺機器上運轉”，如果你不能看到和理解他們之間的不同，那我不知道要和你說什么了

然后，Linus Torvalds進行了諄諄教導——（相當的受用?。?/p>

why_ it works, and it might not work on all machines, but it doesn’t cause regressions (ie the machines it doesn’t work on it _never_ worked on).
– 選擇一：回滾到老的分配模式。那是測試過的。它過了回歸測試。誠然，我們也許不知道為什么那樣能行，并且，即使是那樣也不一定能在所有的機器上工作，但是其沒有讓回歸測試有問題（這個代碼永不可能在不能運行的系統上運行）
And this doesn’t mean “old value for that _one_ machine”. It means “old value for _every_ machine”. So it means we revert the whole bottom-down thing entirely. Not just “change one random number so that the totally different allocation pattern happens to give the same result on one particular machine”.
這并不代表“老的值只能在一臺機器上工作”。這代表“老的值可以工作在每一臺機器上”。所以，我們需要回滾整個代碼改動。而不只是“為了一個特別的機器去修改一個和以前完全不一樣的隨機數”。
– Choice #2: understand exactly _what_ goes wrong, and fix it analytically (ie by _understanding_ the problem, and being able to solve it exactly, and in a way you can argue about without having to resort to “magic happens”).
– 選擇二：真正搞清楚為什么會錯，并且有分析地修改他（理解問題才能真正解決之，并且，只有沒有“魔法發生”的時候你才可以來爭論）
Now, the whole analytic approach (aka “computer sciency” approach), where you can actually think about the problem without having any pesky “reality” impact the solution is obviously the one we tend to prefer. Sadly, it’s seldom the one we can use in reality when it comes to things like resource allocation, since we end up starting off with often buggy approximations of what the actual hardware is all about (ie broken firmware tables).
現在，整個分析方法（亦稱作“計算機科學”的方法）應該是你可以在沒有在外界干擾下真正思考這個問題而得到的解決方案，這很明顯是我們推崇的。只有在極罕見地情況下我們可以在有外界干擾下分析這種資源分配的事，因為我們只有了解倒底是什么樣的硬件，我們才能最終遠離bug（如：錯誤的固件表）
So I’d love to know exactly why one random number works, and why another one doesn’t. But as long as we do _not_ know the “Why” of it, we will have to revert.
所以，我希望你能知道為什么一個隨機數能行，而另一個不行。只要我們不知道，那么我們就不得和回滾整個改動。
It really is that simple. It’s _always_ that simple.
這真的是很簡單，而且這一直是那么簡單。
So the numbers shouldn’t be “magic”, they should have real explanations. And in the absense of real explanation, the model that works is “this is what we’ve always done”. Including, very much, the whole allocation order. Not just one random number on one random machine.
所以，那些數不應該是“magic”的，他們應該有真正的說明。在有真正的說明的情況下，我們的開發模式才會工作。其包括了整個分配順序。不只是那個在任意機器上的隨機數。

Linus

后面的事不用說了。我沒有想到Linux 內核組會有像Yinghai這樣工作的方式，畢竟這是一個黑客級的開發團隊。我個人對這個亂寫代碼的人執零容忍的態度，不管你干過什么，不管你哪里畢業的，不管你簡歷怎么樣，不求甚解隨意寫代碼的人我無法接受。我不知道Yinghai Lu會怎么樣想，他/她會像我在“程序員那些悲催的事兒”中談我經歷那樣知恥而后勇嗎？能得到Linus的教導真是一件很不錯的事。雖然，Linus教導的這些東西，都應該是程序員最最最基本的技能。fix bug一定要fix在root cause上啊，了解一個問題，不但要知其然，還要知其所以然啊，這都是老生長談了。本站有很多提高程序員能力的文章，比如，這篇，這篇，還有這篇。

各位朋友，我真心希望你能從這個小插曲中明白點什么。

—– 更新2011/04/27—–

從本貼的回復中可以看到有朋友說如果時間緊，沒有辦法只能在不求甚解的地去fix bug，因為老板催。我認為這是老板的“急功近利”的問題。我想和大家說一下，你得想清楚你屬于下面那種人：

1. 你的老板給你壓力，讓你不得不亂fix，

2. 你認同只要時間緊bug是可以亂fix的。

如果你屬于1），那我覺得還情由可原，這是管理問題。但這不能成為你對亂fix bug的理由。一般這種問題怎么解決：首先，給一個hot fix去救火，然后，有時間去調查root cause，最后經過分析和測試，給出一個final 的 offical fix。這就是應急的做法，根本不存在什么可以亂fix bug的做法。

如果你屬于2），那么我只能“過激”地說你沒有成為程序員的資質！

另外，快速地fix bug，并不等于，不求甚解的fix bug。大家不要把這兩件事等同。

轉自：http://coolshell.cn/articles/4576.html

轉自標簽:Coding, Linux