立你斯學習記錄

混亂的ARM architecture代碼和存在的問題

每次正式的linux kernel release之後都會有兩周的merge window，在這個窗口期間，kernel各個部分的維護者都會提交各自的patch，將自己測試穩定的代碼請求併入kernel main line。每到這個時候，Linus就會比較繁忙，他需要從各個內核維護者的分支上取得最新代碼並merge到自己的kernel source tree中。Tony Lindgren，內核OMAP development tree的維護者，發送了一個郵件給Linus，請求提交OMAP平台代碼修改，並給出了一些細節描述：

1、簡單介紹本次改動

2、關於如何解決merge conficts。有些git mergetool就可以處理，不能處理的，給出了詳細介紹和解決方案

一切都很平常，也給出了足夠的信息，然而，正是這個pull request引發了一場針對ARM linux的內核代碼的爭論。我相信Linus一定是對ARM相關的代碼早就不爽了，ARM的merge工作量較大倒在其次，主要是他認為ARM很多的代碼都是垃圾，代碼裡面有若干愚蠢的table，而多個人在維護這個table，從而導致了衝突。因此，在處理完OMAP的pull request之後（Linus並非針對OMAP平台，只是Tony Lindgren撞在槍口上了），他發出了怒吼：

Gaah. Guys, this whole ARM thing is a f*cking pain in the ass.

負責ARM linux開發的Russell King臉上掛不住，進行了反駁：事情沒有那麼嚴重，這次的merge conficts就是OMAP和IMX/MXC之間一點協調的問題，不能抹殺整個ARM linux團隊的努力。其他的各個ARM平台維護者也加入討論：ARM平台如何複雜，如何龐大，對於arm linux code我們已經有一些思考，正在進行中……一時間，討論的氣氛有些尖銳，但總體是坦誠和友好的。

對於一件事情，不同層次的人有不同層次的思考。這次爭論涉及的人包括：

1、內核維護者（CPU體系結構無關的代碼）

2、維護ARM系統結構代碼的人

3、維護ARM sub architecture的人（來自各個ARM SOC vendor）

維護ARM sub architecture的人並沒有強烈的使命感，作為公司的一員，他們最大的目標是以最快的速度支持自己公司的SOC，儘快的占領市場。這些人的軟體功力未必強，對linux kernel的理解未必深入（有些人可能很強，但是人在江湖身不由己）。在這樣的情況下，很多SOC specific的代碼都是通過copy and paste，然後稍加修改代碼就提交了。此外，各個ARM vendor的SOC family是一長串的CPU list，每個CPU多多少少有些不同，這時候＃ifdef就充斥了各個原始碼中，讓ARM mach-和plat-目錄下的代碼有些不忍直視。

作為維護ARM體系結構的人，其能力不容置疑。以Russell King為首的team很好的維護了ARM體系結構的代碼。基本上，除了mach-和plat-目錄，其他的目錄中的代碼和目錄組織是很好的。作為ARM linux的維護者，維護一個不斷有新的SOC加入的CPU architecture code的確是一個挑戰。在Intel X86的架構一統天下的時候，任何想正面攻擊Intel的對手都敗下陣來。想要擊倒巨人（或者說想要和巨人並存）必須另闢蹊徑。ARM的策略有兩個，一個是focus在嵌入式應用上，也就意味著要求低功耗，同時也避免了和Intel的正面對抗。另外一個就是博採眾家之長，採用license IP的方式，讓更多的廠商加入ARM建立的生態系統。毫無疑問，ARM公司是成功的，但是這種模式也給ARM linux的維護者帶來了噩夢。越來越多的晶片廠商加入ARM陣營，越來越多的ARM platform相關的代碼被加入到內核，不同廠商的周邊HW block設計又各不相同……

內核維護者是真正對作業系統內核軟體有深入理解的人，他們往往能站在更高的層次上去觀察問題，發現問題。Linus注意到每次merge window中，ARM的代碼變化大約占整個ARCH目錄的60％，他認為這是一個很明顯的符號，意味著ARM linux的代碼可能存在問題。其實，60％這個比率的確很誇張，因為unicore32是在2.6.39 merge window中第一次全新提交，它的代碼是全新的，但是其代碼變化大約占整個ARCH目錄的9.6％（需要提及的是unicore32是一個中國芯）。有些維護ARM linux的人認為這是CPU市場占用率的體現，不是問題，直到內核維護者貼出實際的代碼並指出問題所在。內核維護者當然想linux kernel支持更多的硬體平台，但是他們更願意為linux kernel制定更長遠的規劃。例如：對於各種繁雜的ARM平台，用一個kernel image來支持。

經過爭論，確定的問題如下：

1、ARM linux缺少platform（各個ARM sub architecture，或者說各個SOC）之間的協調，導致arm linux的代碼有重複。值得一提的是在本次爭論之前，ARM維護者已經進行了不少相關的工作（例如PM和clock tree）來抽象相同的功能模塊。

2、ARM linux中大量的board specific的原始碼應該踢出kernel，否則這些垃圾代碼和table會影響linux kernel的長期目標。

3、各個sub architecture的維護者直接提交給Linux併入主線的機制缺乏層次。

四、新內核的解決之道

針對ARM linux的現狀，最需要解決的是人員問題，也就是如何整合ARM sub architecture（各個ARM Vendor）的資源。因此，內核社區成立了一個ARM sub architecture的team，該team主要負責協調各個ARM廠商的代碼（not ARM core part），Russell King繼續負責ARM core part的代碼。此外，建立一個ARM platform consolidation tree。ARM sub architecture team負責review各個sub architecture維護者提交的代碼，並在ARM platform consolidation tree上維護。在下一個merge window到來的時候，將patch發送給Linus。

針對重複的代碼問題，如果不同的SOC使用了相同的IP block（例如I2C controller），那麼這個driver的code要從各個arch/arm/mach-xxx中獨立出來，變成一個通用的模塊供各個SOC specific的模塊使用。移動到哪個目錄呢？對於I2C或者USB OTG而言，這些HW block的驅動當然應該移動到kernel/drivers目錄。因為，對於這些外設，可能是in-chip，也可能是off-chip的，但是對於軟體而言，它們是沒有差別的（或者說好的軟體抽象應該掩蓋底層硬體的不同）。對於那些system level的code呢？例如clock control、interrupt control。其實這些也不是ARM-specific，應該屬於linux kernel的核心代碼，應該放到linux/kernel目錄下，屬於core-Linux-kernel frameworks。當然對於ARM平台，也需要保存一些和framework交互的code，這些code叫做ARM SoC core architecture code。OK，總結一下：

1、ARM的核心代碼仍然保存在arch/arm目錄下

2、ARM SoC core architecture code保存在arch/arm目錄下

3、ARM SOC的周邊外設模塊的驅動保存在drivers目錄下

4、ARM SOC的特定代碼在arch/arm/mach-xxx目錄下

5、ARM SOC board specific的代碼被移除，由Device Tree機制來負責傳遞硬體拓撲和硬體資源信息。

OK，終於來到了Device Tree了。本質上，Device Tree改變了原來用hardcode方式將HW 配置信息嵌入到內核代碼的方法，改用bootloader傳遞一個DB的形式。對於基於ARM CPU的嵌入式系統，我們習慣於針對每一個platform進行內核的編譯。但是隨著ARM在消費類電子上的廣泛應用（甚至桌面系統、伺服器系統），我們期望ARM能夠象X86那樣用一個kernel image來支持多個platform。在這種情況下，如果我們認為kernel是一個black box，那麼其輸入參數應該包括：

1、識別platform的信息

2、runtime的配置參數

3、設備的拓撲結構以及特性

對於嵌入式系統，在系統啟動階段，bootloader會加載內核並將控制權轉交給內核，此外，還需要把上述的三個參數信息傳遞給kernel，以便kernel可以有較大的靈活性。在linux kernel中，Device Tree的設計目標就是如此。

混亂的ARM architecture代碼和存在的問題

每次正式的linux kernel release之後都會有兩周的merge window，在這個窗口期間，kernel各個部分的維護者都會提交各自的patch，將自己測試穩定的代碼請求併入kernel main line。每到這個時候，Linus就會比較繁忙，他需要從各個內核維護者的分支上取得最新代碼並merge到自己的kernel source tree中。Tony Lindgren，內核OMAP development tree的維護者，發送了一個郵件給Linus，請求提交OMAP平台代碼修改，並給出了一些細節描述：

1、簡單介紹本次改動

2、關於如何解決merge conficts。有些git mergetool就可以處理，不能處理的，給出了詳細介紹和解決方案

一切都很平常，也給出了足夠的信息，然而，正是這個pull request引發了一場針對ARM linux的內核代碼的爭論。我相信Linus一定是對ARM相關的代碼早就不爽了，ARM的merge工作量較大倒在其次，主要是他認為ARM很多的代碼都是垃圾，代碼裡面有若干愚蠢的table，而多個人在維護這個table，從而導致了衝突。因此，在處理完OMAP的pull request之後（Linus並非針對OMAP平台，只是Tony Lindgren撞在槍口上了），他發出了怒吼：

Gaah. Guys, this whole ARM thing is a f*cking pain in the ass.

負責ARM linux開發的Russell King臉上掛不住，進行了反駁：事情沒有那麼嚴重，這次的merge conficts就是OMAP和IMX/MXC之間一點協調的問題，不能抹殺整個ARM linux團隊的努力。其他的各個ARM平台維護者也加入討論：ARM平台如何複雜，如何龐大，對於arm linux code我們已經有一些思考，正在進行中……一時間，討論的氣氛有些尖銳，但總體是坦誠和友好的。

對於一件事情，不同層次的人有不同層次的思考。這次爭論涉及的人包括：

1、內核維護者（CPU體系結構無關的代碼）

2、維護ARM系統結構代碼的人

3、維護ARM sub architecture的人（來自各個ARM SOC vendor）

維護ARM sub architecture的人並沒有強烈的使命感，作為公司的一員，他們最大的目標是以最快的速度支持自己公司的SOC，儘快的占領市場。這些人的軟體功力未必強，對linux kernel的理解未必深入（有些人可能很強，但是人在江湖身不由己）。在這樣的情況下，很多SOC specific的代碼都是通過copy and paste，然後稍加修改代碼就提交了。此外，各個ARM vendor的SOC family是一長串的CPU list，每個CPU多多少少有些不同，這時候＃ifdef就充斥了各個原始碼中，讓ARM mach-和plat-目錄下的代碼有些不忍直視。

作為維護ARM體系結構的人，其能力不容置疑。以Russell King為首的team很好的維護了ARM體系結構的代碼。基本上，除了mach-和plat-目錄，其他的目錄中的代碼和目錄組織是很好的。作為ARM linux的維護者，維護一個不斷有新的SOC加入的CPU architecture code的確是一個挑戰。在Intel X86的架構一統天下的時候，任何想正面攻擊Intel的對手都敗下陣來。想要擊倒巨人（或者說想要和巨人並存）必須另闢蹊徑。ARM的策略有兩個，一個是focus在嵌入式應用上，也就意味著要求低功耗，同時也避免了和Intel的正面對抗。另外一個就是博採眾家之長，採用license IP的方式，讓更多的廠商加入ARM建立的生態系統。毫無疑問，ARM公司是成功的，但是這種模式也給ARM linux的維護者帶來了噩夢。越來越多的晶片廠商加入ARM陣營，越來越多的ARM platform相關的代碼被加入到內核，不同廠商的周邊HW block設計又各不相同……

內核維護者是真正對作業系統內核軟體有深入理解的人，他們往往能站在更高的層次上去觀察問題，發現問題。Linus注意到每次merge window中，ARM的代碼變化大約占整個ARCH目錄的60％，他認為這是一個很明顯的符號，意味著ARM linux的代碼可能存在問題。其實，60％這個比率的確很誇張，因為unicore32是在2.6.39 merge window中第一次全新提交，它的代碼是全新的，但是其代碼變化大約占整個ARCH目錄的9.6％（需要提及的是unicore32是一個中國芯）。有些維護ARM linux的人認為這是CPU市場占用率的體現，不是問題，直到內核維護者貼出實際的代碼並指出問題所在。內核維護者當然想linux kernel支持更多的硬體平台，但是他們更願意為linux kernel制定更長遠的規劃。例如：對於各種繁雜的ARM平台，用一個kernel image來支持。

經過爭論，確定的問題如下：

1、ARM linux缺少platform（各個ARM sub architecture，或者說各個SOC）之間的協調，導致arm linux的代碼有重複。值得一提的是在本次爭論之前，ARM維護者已經進行了不少相關的工作（例如PM和clock tree）來抽象相同的功能模塊。

2、ARM linux中大量的board specific的原始碼應該踢出kernel，否則這些垃圾代碼和table會影響linux kernel的長期目標。

3、各個sub architecture的維護者直接提交給Linux併入主線的機制缺乏層次。

四、新內核的解決之道

針對ARM linux的現狀，最需要解決的是人員問題，也就是如何整合ARM sub architecture（各個ARM Vendor）的資源。因此，內核社區成立了一個ARM sub architecture的team，該team主要負責協調各個ARM廠商的代碼（not ARM core part），Russell King繼續負責ARM core part的代碼。此外，建立一個ARM platform consolidation tree。ARM sub architecture team負責review各個sub architecture維護者提交的代碼，並在ARM platform consolidation tree上維護。在下一個merge window到來的時候，將patch發送給Linus。

針對重複的代碼問題，如果不同的SOC使用了相同的IP block（例如I2C controller），那麼這個driver的code要從各個arch/arm/mach-xxx中獨立出來，變成一個通用的模塊供各個SOC specific的模塊使用。移動到哪個目錄呢？對於I2C或者USB OTG而言，這些HW block的驅動當然應該移動到kernel/drivers目錄。因為，對於這些外設，可能是in-chip，也可能是off-chip的，但是對於軟體而言，它們是沒有差別的（或者說好的軟體抽象應該掩蓋底層硬體的不同）。對於那些system level的code呢？例如clock control、interrupt control。其實這些也不是ARM-specific，應該屬於linux kernel的核心代碼，應該放到linux/kernel目錄下，屬於core-Linux-kernel frameworks。當然對於ARM平台，也需要保存一些和framework交互的code，這些code叫做ARM SoC core architecture code。OK，總結一下：

1、ARM的核心代碼仍然保存在arch/arm目錄下

2、ARM SoC core architecture code保存在arch/arm目錄下

3、ARM SOC的周邊外設模塊的驅動保存在drivers目錄下

4、ARM SOC的特定代碼在arch/arm/mach-xxx目錄下

5、ARM SOC board specific的代碼被移除，由Device Tree機制來負責傳遞硬體拓撲和硬體資源信息。

OK，終於來到了Device Tree了。本質上，Device Tree改變了原來用hardcode方式將HW 配置信息嵌入到內核代碼的方法，改用bootloader傳遞一個DB的形式。對於基於ARM CPU的嵌入式系統，我們習慣於針對每一個platform進行內核的編譯。但是隨著ARM在消費類電子上的廣泛應用（甚至桌面系統、伺服器系統），我們期望ARM能夠象X86那樣用一個kernel image來支持多個platform。在這種情況下，如果我們認為kernel是一個black box，那麼其輸入參數應該包括：

1、識別platform的信息

2、runtime的配置參數

3、設備的拓撲結構以及特性

對於嵌入式系統，在系統啟動階段，bootloader會加載內核並將控制權轉交給內核，此外，還需要把上述的三個參數信息傳遞給kernel，以便kernel可以有較大的靈活性。在linux kernel中，Device Tree的設計目標就是如此。

混亂的ARM architecture代碼和存在的問題

每次正式的linux kernel release之後都會有兩周的merge window，在這個窗口期間，kernel各個部分的維護者都會提交各自的patch，將自己測試穩定的代碼請求併入kernel main line。每到這個時候，Linus就會比較繁忙，他需要從各個內核維護者的分支上取得最新代碼並merge到自己的kernel source tree中。Tony Lindgren，內核OMAP development tree的維護者，發送了一個郵件給Linus，請求提交OMAP平台代碼修改，並給出了一些細節描述：

1、簡單介紹本次改動

2、關於如何解決merge conficts。有些git mergetool就可以處理，不能處理的，給出了詳細介紹和解決方案

一切都很平常，也給出了足夠的信息，然而，正是這個pull request引發了一場針對ARM linux的內核代碼的爭論。我相信Linus一定是對ARM相關的代碼早就不爽了，ARM的merge工作量較大倒在其次，主要是他認為ARM很多的代碼都是垃圾，代碼裡面有若干愚蠢的table，而多個人在維護這個table，從而導致了衝突。因此，在處理完OMAP的pull request之後（Linus並非針對OMAP平台，只是Tony Lindgren撞在槍口上了），他發出了怒吼：

Gaah. Guys, this whole ARM thing is a f*cking pain in the ass.

負責ARM linux開發的Russell King臉上掛不住，進行了反駁：事情沒有那麼嚴重，這次的merge conficts就是OMAP和IMX/MXC之間一點協調的問題，不能抹殺整個ARM linux團隊的努力。其他的各個ARM平台維護者也加入討論：ARM平台如何複雜，如何龐大，對於arm linux code我們已經有一些思考，正在進行中……一時間，討論的氣氛有些尖銳，但總體是坦誠和友好的。

對於一件事情，不同層次的人有不同層次的思考。這次爭論涉及的人包括：

1、內核維護者（CPU體系結構無關的代碼）

2、維護ARM系統結構代碼的人

3、維護ARM sub architecture的人（來自各個ARM SOC vendor）

維護ARM sub architecture的人並沒有強烈的使命感，作為公司的一員，他們最大的目標是以最快的速度支持自己公司的SOC，儘快的占領市場。這些人的軟體功力未必強，對linux kernel的理解未必深入（有些人可能很強，但是人在江湖身不由己）。在這樣的情況下，很多SOC specific的代碼都是通過copy and paste，然後稍加修改代碼就提交了。此外，各個ARM vendor的SOC family是一長串的CPU list，每個CPU多多少少有些不同，這時候＃ifdef就充斥了各個原始碼中，讓ARM mach-和plat-目錄下的代碼有些不忍直視。

作為維護ARM體系結構的人，其能力不容置疑。以Russell King為首的team很好的維護了ARM體系結構的代碼。基本上，除了mach-和plat-目錄，其他的目錄中的代碼和目錄組織是很好的。作為ARM linux的維護者，維護一個不斷有新的SOC加入的CPU architecture code的確是一個挑戰。在Intel X86的架構一統天下的時候，任何想正面攻擊Intel的對手都敗下陣來。想要擊倒巨人（或者說想要和巨人並存）必須另闢蹊徑。ARM的策略有兩個，一個是focus在嵌入式應用上，也就意味著要求低功耗，同時也避免了和Intel的正面對抗。另外一個就是博採眾家之長，採用license IP的方式，讓更多的廠商加入ARM建立的生態系統。毫無疑問，ARM公司是成功的，但是這種模式也給ARM linux的維護者帶來了噩夢。越來越多的晶片廠商加入ARM陣營，越來越多的ARM platform相關的代碼被加入到內核，不同廠商的周邊HW block設計又各不相同……

內核維護者是真正對作業系統內核軟體有深入理解的人，他們往往能站在更高的層次上去觀察問題，發現問題。Linus注意到每次merge window中，ARM的代碼變化大約占整個ARCH目錄的60％，他認為這是一個很明顯的符號，意味著ARM linux的代碼可能存在問題。其實，60％這個比率的確很誇張，因為unicore32是在2.6.39 merge window中第一次全新提交，它的代碼是全新的，但是其代碼變化大約占整個ARCH目錄的9.6％（需要提及的是unicore32是一個中國芯）。有些維護ARM linux的人認為這是CPU市場占用率的體現，不是問題，直到內核維護者貼出實際的代碼並指出問題所在。內核維護者當然想linux kernel支持更多的硬體平台，但是他們更願意為linux kernel制定更長遠的規劃。例如：對於各種繁雜的ARM平台，用一個kernel image來支持。

經過爭論，確定的問題如下：

1、ARM linux缺少platform（各個ARM sub architecture，或者說各個SOC）之間的協調，導致arm linux的代碼有重複。值得一提的是在本次爭論之前，ARM維護者已經進行了不少相關的工作（例如PM和clock tree）來抽象相同的功能模塊。

2、ARM linux中大量的board specific的原始碼應該踢出kernel，否則這些垃圾代碼和table會影響linux kernel的長期目標。

3、各個sub architecture的維護者直接提交給Linux併入主線的機制缺乏層次。

四、新內核的解決之道

針對ARM linux的現狀，最需要解決的是人員問題，也就是如何整合ARM sub architecture（各個ARM Vendor）的資源。因此，內核社區成立了一個ARM sub architecture的team，該team主要負責協調各個ARM廠商的代碼（not ARM core part），Russell King繼續負責ARM core part的代碼。此外，建立一個ARM platform consolidation tree。ARM sub architecture team負責review各個sub architecture維護者提交的代碼，並在ARM platform consolidation tree上維護。在下一個merge window到來的時候，將patch發送給Linus。

針對重複的代碼問題，如果不同的SOC使用了相同的IP block（例如I2C controller），那麼這個driver的code要從各個arch/arm/mach-xxx中獨立出來，變成一個通用的模塊供各個SOC specific的模塊使用。移動到哪個目錄呢？對於I2C或者USB OTG而言，這些HW block的驅動當然應該移動到kernel/drivers目錄。因為，對於這些外設，可能是in-chip，也可能是off-chip的，但是對於軟體而言，它們是沒有差別的（或者說好的軟體抽象應該掩蓋底層硬體的不同）。對於那些system level的code呢？例如clock control、interrupt control。其實這些也不是ARM-specific，應該屬於linux kernel的核心代碼，應該放到linux/kernel目錄下，屬於core-Linux-kernel frameworks。當然對於ARM平台，也需要保存一些和framework交互的code，這些code叫做ARM SoC core architecture code。OK，總結一下：

1、ARM的核心代碼仍然保存在arch/arm目錄下

2、ARM SoC core architecture code保存在arch/arm目錄下

3、ARM SOC的周邊外設模塊的驅動保存在drivers目錄下

4、ARM SOC的特定代碼在arch/arm/mach-xxx目錄下

5、ARM SOC board specific的代碼被移除，由Device Tree機制來負責傳遞硬體拓撲和硬體資源信息。

OK，終於來到了Device Tree了。本質上，Device Tree改變了原來用hardcode方式將HW 配置信息嵌入到內核代碼的方法，改用bootloader傳遞一個DB的形式。對於基於ARM CPU的嵌入式系統，我們習慣於針對每一個platform進行內核的編譯。但是隨著ARM在消費類電子上的廣泛應用（甚至桌面系統、伺服器系統），我們期望ARM能夠象X86那樣用一個kernel image來支持多個platform。在這種情況下，如果我們認為kernel是一個black box，那麼其輸入參數應該包括：

1、識別platform的信息

2、runtime的配置參數

3、設備的拓撲結構以及特性

對於嵌入式系統，在系統啟動階段，bootloader會加載內核並將控制權轉交給內核，此外，還需要把上述的三個參數信息傳遞給kernel，以便kernel可以有較大的靈活性。在linux kernel中，Device Tree的設計目標就是如此。