最近新釋出的 Linux v3.3 增加一個新的 C6x 家族 CPU 支援。有用過 TI 平台的人都知道，C6x 是 TI 開發的數位信號處理器，主要使用於需要大量運算資源，如多媒體編解碼之類的應用。過去 TI DSP 上幾乎所有的軟體架構，包括 RTOS、函式庫、編譯器、IDE 等等，皆是 TI 所開發，當然也都是專屬軟體，且若無簽署 NDA，許多技術文件並不是那麼容易取得，因此相對於其他如 ARM 等較為通用的平台而言，DSP 是較為封閉的體系。許多在 Linux 下執行的應用程式，無法輕易地移植至 DSP 平台，想要實現相同的功能，就得自己從頭寫起，無形中也是一種麻煩。
是故若官方核心對於 DSP 的支援能夠逐步完善，未來或許有機會能夠將原來在 ARM 執行的程式移植至 DSP 端執行；甚至或可再更進一步，在 DaVinci 這類異質性多核心平台上，利用如 llvm 的技術，預先將應用程式編譯為中間碼，到執行時期時才根據系統負載來決定要在那一個 core 執行，如此便能提供系統執行時期更多的彈性。
參考資料：
[1] Upcoming DSP architectures
[2] c6x Linux project
2012年4月1日 星期日
2011年6月4日 星期六
Linux 即將邁入 3.0
約在五月底時，Linus 宣布了一個重大的決定，就是將開發近八年的 2.6 系列做一個結尾，並在即將 20 周年的時刻，發布 Linux 3.0。
3.0 的發布將會是一個重大的里程碑；即使它相較於 2.6.39，並未有什麼大太的改變，不過卻象徵著 Linux 的開發已經進入了一個成熟、開花結果的階段。雖然在桌面市場上仍然無法取代 Windows，但在嵌入式系統領域中卻取得了重大的成就，連帶也增加了許多相關的工作機會，並吸引優秀的軟體人才進入這個領域。從 20 週年的這個時刻來看，我想 Linux 算是相當地成功的。
當然為了讓 3.0 這個版號更為名副其實，Linus 刻意縮短了 merge window 的時間，並採取較為嚴格的審查，以確保只有真正重要的修正才會被納入。另外就是將來的穩定版的版號將不再採取三個數字的表現方式，而是採用 3.x 的方式，第三個數字則留給 maintenance team 使用。
P.S. 當初之所以會有三個數字的版號，可能是源自於從 0.99 到 1.0 的開發期間，為了不要一下子就跳到 1.0，所玩的數字遊戲。於是從這時開始，就出現了 0.99.1, 0.99.2 …… 等版號。如今 Linux 已非當年的吳下阿蒙，且開發時程也相當地制度化了，三個數字的版號已不再有實質上的意義。或許 Linus 也是基於這樣的理由，而做出這個決定吧。
3.0 的發布將會是一個重大的里程碑；即使它相較於 2.6.39，並未有什麼大太的改變，不過卻象徵著 Linux 的開發已經進入了一個成熟、開花結果的階段。雖然在桌面市場上仍然無法取代 Windows，但在嵌入式系統領域中卻取得了重大的成就，連帶也增加了許多相關的工作機會，並吸引優秀的軟體人才進入這個領域。從 20 週年的這個時刻來看，我想 Linux 算是相當地成功的。
當然為了讓 3.0 這個版號更為名副其實，Linus 刻意縮短了 merge window 的時間，並採取較為嚴格的審查，以確保只有真正重要的修正才會被納入。另外就是將來的穩定版的版號將不再採取三個數字的表現方式，而是採用 3.x 的方式，第三個數字則留給 maintenance team 使用。
P.S. 當初之所以會有三個數字的版號，可能是源自於從 0.99 到 1.0 的開發期間，為了不要一下子就跳到 1.0，所玩的數字遊戲。於是從這時開始，就出現了 0.99.1, 0.99.2 …… 等版號。如今 Linux 已非當年的吳下阿蒙，且開發時程也相當地制度化了，三個數字的版號已不再有實質上的意義。或許 Linus 也是基於這樣的理由，而做出這個決定吧。
2009年2月13日 星期五
Poky Linux 建構系統使用感想
最近為了要建立一個完整可供核心掛載的檔案系統，去玩一玩了 Poky 這個嵌入式套件。無可否認的，它所根基的 OpenEmbedded 是個很有彈性的套件建構系統，在已支援的開發板上，只要改一些設定，就可從無到有建構核心及所需的檔案系統映象 (file system image)，並且會幫你處理套件間相依性的問題，也可以只建構特定套件，打包成 ipkg 或 deb 檔以供其他系統使用。有過土法煉鋼、自己抓原始碼回來編譯的痛苦經驗的人，就會了解這個功能是多麼地令人叫好。
雖然功能強大，但若要加入新的開發板的支援，或是要解決某個套件不能順利編譯的問題，你就會發現，它的設定檔也是異常的複雜難懂；每個設定檔會去引用其他共享的檔案，並且預先設定一大堆變數。有些變數是在目前檔案被設定，有些則是在被引用時才設定。而被引用的檔案又會去引用其他的檔案……沒完沒了。
就在不久前，uClibc 發生編譯錯誤 (poky 3.1.1)，從錯誤訊息看來，發現是硬體架構設定錯誤所致。但找了老半天，就是不知道應該要改那個設定檔，令人懊惱。花了一個下午的時間，才找到問題的關鍵，修正後，這才能順利編譯。我另外把它做成了一個 patch，但我沒有網頁空間可以放，有相同問題的朋友可以來找我要，或有朋友願意提供他的空間也成。
延伸閱讀：
Embedded Linux 系統性的教學看法
Embedded Linux 應用的痛處: OpenEmbedded
雖然功能強大，但若要加入新的開發板的支援，或是要解決某個套件不能順利編譯的問題，你就會發現，它的設定檔也是異常的複雜難懂；每個設定檔會去引用其他共享的檔案，並且預先設定一大堆變數。有些變數是在目前檔案被設定，有些則是在被引用時才設定。而被引用的檔案又會去引用其他的檔案……沒完沒了。
就在不久前，uClibc 發生編譯錯誤 (poky 3.1.1)，從錯誤訊息看來，發現是硬體架構設定錯誤所致。但找了老半天，就是不知道應該要改那個設定檔，令人懊惱。花了一個下午的時間，才找到問題的關鍵，修正後，這才能順利編譯。我另外把它做成了一個 patch，但我沒有網頁空間可以放，有相同問題的朋友可以來找我要，或有朋友願意提供他的空間也成。
延伸閱讀：
Embedded Linux 系統性的教學看法
Embedded Linux 應用的痛處: OpenEmbedded
2008年9月12日 星期五
[好文] 如何加入 Linux 開發社群
How to participate in the Linux Community
http://ldn.linuxfoundation.org/book/how-participate-linux-community
就在幾個月前，動心起念想要貢獻一些程式碼時，還真是不知該如何入門；深怕一個不小心，也許是程式的錯誤，或是英文不好引起誤會，或不了解某些規矩，而被 list 上的開發者給打槍，並回以鄙夷的指責。不過在 post 了幾個 patch 之後，事實證明了我是多慮了。當然還是有些規矩要遵守，只是犯了錯也沒那麼嚴重，通常開發者會好心提醒你該作什麼事，改回來就好，社群仍然會歡迎你的加入。
當然如果可以有一些文件教導我們這些新人，豈不更好？幸好有這本小書的出現，替我們指點迷津。24 頁的內容包含新進開發者該有的心態，以及該如何和社群互動、修改程式、準備及上傳 patch、撰寫信件的注意事項、開發者常犯的錯誤等等，足夠菜鳥們在正式踏入前有個心理準備，而我也從中受惠許多，發現了一些自己不曾注意到的小細節，或許可以再做得更好。
總之，強烈推薦新進開發者一定要讀讀這本書。
http://ldn.linuxfoundation.org/book/how-participate-linux-community
就在幾個月前，動心起念想要貢獻一些程式碼時，還真是不知該如何入門；深怕一個不小心，也許是程式的錯誤，或是英文不好引起誤會，或不了解某些規矩，而被 list 上的開發者給打槍，並回以鄙夷的指責。不過在 post 了幾個 patch 之後，事實證明了我是多慮了。當然還是有些規矩要遵守，只是犯了錯也沒那麼嚴重，通常開發者會好心提醒你該作什麼事，改回來就好，社群仍然會歡迎你的加入。
當然如果可以有一些文件教導我們這些新人，豈不更好？幸好有這本小書的出現，替我們指點迷津。24 頁的內容包含新進開發者該有的心態，以及該如何和社群互動、修改程式、準備及上傳 patch、撰寫信件的注意事項、開發者常犯的錯誤等等，足夠菜鳥們在正式踏入前有個心理準備，而我也從中受惠許多，發現了一些自己不曾注意到的小細節，或許可以再做得更好。
總之，強烈推薦新進開發者一定要讀讀這本書。
2008年7月1日 星期二
發送第一個 patch
大約在上星期的時候，我發送了第一個針對開發板修改的 patch 後，Ben Dooks 隨後不久便回覆我，除了指出我一個未察覺到的錯誤外，還希望我針對一些他不明瞭的部分再多做說明。當我回答後，他似乎覺得沒什麼大問題，便要我針對之前的 review comment 再做修改，並且先將這些修正修補到一份乾淨的核心原始碼樹中做編譯測試，確定沒問題後，再把修改過的 patch 送上來。
經過了幾天，在上星期六，我再發送了第二個版本的 patch，這次就沒什麼問題了，Ben 也會將這份修正加入到他的合併清單之中。
當然對於嫻熟於開放原始碼社群運作模式的人，送 patch 是家常便飯，沒什麼值得大書特書的；不過對於像我這種新手來說卻是一種很奇妙的體驗，藉由送修正、審查修正、再送修正…這樣多次往返的流程，讓程式碼更臻完美，得以一種簡潔的樣貌合併進入主流核心之中。正如 Thomas Gleixner 所言，和核心團隊一同運作，除了增進程式碼的品質，開發者自身的能力也會在這樣互動的過程中逐步提升，這是一個多贏的局面。
我想，我未來應該還會再繼續送 patch 吧。
經過了幾天，在上星期六，我再發送了第二個版本的 patch，這次就沒什麼問題了，Ben 也會將這份修正加入到他的合併清單之中。
當然對於嫻熟於開放原始碼社群運作模式的人，送 patch 是家常便飯，沒什麼值得大書特書的；不過對於像我這種新手來說卻是一種很奇妙的體驗，藉由送修正、審查修正、再送修正…這樣多次往返的流程，讓程式碼更臻完美，得以一種簡潔的樣貌合併進入主流核心之中。正如 Thomas Gleixner 所言，和核心團隊一同運作，除了增進程式碼的品質，開發者自身的能力也會在這樣互動的過程中逐步提升，這是一個多贏的局面。
我想，我未來應該還會再繼續送 patch 吧。
2008年6月30日 星期一
為何要和主流核心保持互動？
就在幾天前我送出第一個針對開發板移植的 patch 後，Eric Miao 看到了我的訊息，便利用 gTalk 丟水球來聊一聊。Eric 是 PXA 架構的維護者，本身也在 Marvell 工作。他以為我是開發版廠商裡頭的人，我跟他說我是以個人名義做開發，他才了解怎麼一回事，並開玩笑地說我可以去向他們要錢了。
不過他提到，大陸在做開發板的公司，由於成本考量，往往移植的核心都固定在某一個版本，而不願意跟著主流核心版本做維護，這引發了我另外一種的思考。不錯，當公司的產品還不夠普遍時，確實需要另外請人維護並確保新版核心可以在產品上運作；不過將修改過的原始碼合併至主流版本的同時，你也達到了廣告的效果，告訴人們你有在賣這類產品，並且最新版的核心直接就可以在上面運作。能夠增加曝光的機會，代表的是可能會有更多的訂單進來。當你的銷售量達到一定規模、夠普遍的時候，你不需要請人，自然就會有人來接手維護的工作，那麼額外的人事成本就能夠節省下來。
所以問題在於，公司願不願意多花些錢做點廣告，介紹你的產品，讓全世界的人都能認識你的產品，並為你的產品多增加些潛在的客群？
當然，對我而言，動機就單純得多。我只是想要在上面跑最新版的核心，但不希望每次新版釋出就要再改一次程式碼，於是將修正貢獻合併回主流核心就成了最佳的選擇。
一點意見，還請不吝指教。
不過他提到，大陸在做開發板的公司，由於成本考量，往往移植的核心都固定在某一個版本，而不願意跟著主流核心版本做維護，這引發了我另外一種的思考。不錯，當公司的產品還不夠普遍時，確實需要另外請人維護並確保新版核心可以在產品上運作；不過將修改過的原始碼合併至主流版本的同時，你也達到了廣告的效果，告訴人們你有在賣這類產品，並且最新版的核心直接就可以在上面運作。能夠增加曝光的機會，代表的是可能會有更多的訂單進來。當你的銷售量達到一定規模、夠普遍的時候，你不需要請人，自然就會有人來接手維護的工作，那麼額外的人事成本就能夠節省下來。
所以問題在於，公司願不願意多花些錢做點廣告，介紹你的產品，讓全世界的人都能認識你的產品，並為你的產品多增加些潛在的客群？
當然，對我而言，動機就單純得多。我只是想要在上面跑最新版的核心，但不希望每次新版釋出就要再改一次程式碼，於是將修正貢獻合併回主流核心就成了最佳的選擇。
一點意見，還請不吝指教。
訂閱：
文章 (Atom)