Linux系統(tǒng)成功地修復了很多bug
Linux系統(tǒng)還是比較常用的，于是我研究了一下Linux系統(tǒng)，在這里拿出來和大家分享一下，希望對大家有用。每當Linux系統(tǒng)崩潰之時，人們看到的不是微軟視窗操作系統(tǒng)那種經(jīng)典的“藍屏”現(xiàn)象，取而代之的是顯示系統(tǒng)崩潰報告簽名（被稱作“oops”，該單詞是吃驚的感嘆詞，相當于“哎呀”），以此來幫助開發(fā)人員弄清系統(tǒng)出錯的原因。
也許有人舉得這個稱呼有點傻傻的感覺，但是這種Linux系統(tǒng)的特性有著其不可取代的作用。跟蹤這些“oops”是Kerneloops機構(gòu)的一個職責。根據(jù)這些提交的系統(tǒng)崩潰報告簽名，這家機構(gòu)已經(jīng)成功地修復了很多的Linux系統(tǒng) bug，從而在很大程度上提升了Linux系統(tǒng)核心（kernel）質(zhì)量。
這些點點滴滴的跟蹤“oops”以及修復系統(tǒng)bug的努力已經(jīng)成為了Linux系統(tǒng)獲得眾多企業(yè)用戶和其他用戶青睞的重要因素。英特爾開源技術中心kernel工程師Arjan van de Ven向InternetNews.com網(wǎng)站透露表示。
“Linux系統(tǒng)所謂的‘oops’就相當于微軟Windows系統(tǒng)的‘藍屏’，這兩個概念其實在產(chǎn)生原因和工作原理上都是一樣的。我們Linux沒有在整個屏幕上涂上藍色和錯誤代碼信息，而是在上面顯示系統(tǒng)崩潰報告簽名。”
其實Kerneloops機構(gòu)是由Van de Ven獨自經(jīng)營的，盡管“oops”的搜集檢測和報告途徑大部分都是自動提交上來，但是Kerneloops還是為Fedora、OpenSUSE以及 Debian的用戶提供了專門提交“oops”記錄的客戶端程序。
隨著Linux市場份額的逐步增長，這個開源系統(tǒng)逐步走向那些非技術性的商業(yè)用戶和一般用戶，如此看來“oops”記錄的提交功能就顯得越發(fā)重要，像諸如紅帽子這樣子的大型Linux產(chǎn)商都已經(jīng)把“oops”記錄客戶端提交功能設置成其 Fedora Linux系統(tǒng)的默認選項。
Van de Ven解釋道，“許多的用戶都不知道如何去發(fā)現(xiàn)這些系統(tǒng)問題以及將BUG發(fā)送到哪里。安裝了“oops”記錄的提交客戶端的用戶僅僅只需輕輕點擊一下鼠標，我相信絕大多數(shù)的用戶還是傾向于這種簡便的提交方式?！?/P>
Fedora項目領軍人Paul Frields向InternetNews.com網(wǎng)站透露表示，“Kerneloops程序包能夠自動將Linux系統(tǒng)內(nèi)核崩潰信息傳遞到一個存儲庫，Linux系統(tǒng)核心維護人員就可以調(diào)用這個存儲庫的信息來進行有針對性的系統(tǒng)診斷并且修復系統(tǒng)的BUG?！?/P>
Frields稱，“Fedora加入其中是因為我們積極地跟蹤系統(tǒng)內(nèi)核崩潰信息。Kerneloops的功能將會對我們與諸如內(nèi)核開發(fā)社區(qū)之類（kernel developer community）上游軟件提供商之間的合作提供極大的支持。Fedora的推廣既有符合社區(qū)的利益又能對我們根據(jù)“oops”記錄修改系統(tǒng)BUG來提升內(nèi)核代碼質(zhì)量的工作帶來很多幫助。
此外，Kerneloops可以還通過Linux系統(tǒng)內(nèi)核郵件列表（Linux Kernel Mailing List是諸如Linux內(nèi)核bug和相關設計的重要技術問題的“集中營”，以下簡稱LKML）來收集“oops”記錄。此外Kerneloops還周期性地向LKML發(fā)送典型的嚴重內(nèi)核bug郵件信息。Van de Ven指出，如果有足夠的用戶反饋信息來反映一個內(nèi)核bug問題，那么內(nèi)核開發(fā)人員就會據(jù)此跟蹤這個系統(tǒng)bug并盡全力修正。
Van de Ven表示，“一般來說，內(nèi)核開發(fā)人員是看重Kerneloops的，畢竟我（Kerneloops）提供的內(nèi)核bug越多，他們掌握的信息則越多。如果某個系統(tǒng)問題只有一個提交的報告，那么這很可能就是個案而已，但是如果有500份提交報告反映的是同一個系統(tǒng)問題，那么這個問題就是這些內(nèi)核開發(fā)人員所要解決的一個真正的系統(tǒng)bug?！?/P>
因此Van de Ven認為這些提交報告從很大程度上有助于Linux系統(tǒng)開發(fā)人員的bug修正工作，這對整個系統(tǒng)內(nèi)核質(zhì)量的改善起到了積極的作用?？紤]到Kerneloops組織所獲得的提交報告數(shù)量因不同版本的內(nèi)核系統(tǒng)而異，所以提交報告的具體數(shù)目難以衡量。
Van de Ven表示，“目前我們致力解決的就是讓眾多用戶深受其害系統(tǒng)bug。如果你看這些各不相同的bug數(shù)量，你會感到有些疑惑。2.6.25版本內(nèi)核一共有 1300多個bug，但是這其中有半數(shù)之多的bug只發(fā)生過一次。我們的確修復了好多bug，往往這些我們修復過的bug才是那些真的亟待解決的棘手問題。
對于目前的2.6.27RC（候選版本）的Linux內(nèi)核而言，Van de Ven以及看到了一些早期問題的趨勢，這其中最顯著的就是在USB設備使用時移除相關驅(qū)動所導致的問題，這會在二十大“oops”當中排名前五位。Van de Ven表示，“就目前而言，這可是最熱門的系統(tǒng)內(nèi)核bug之一?！?/P>
改善提高整個Linux內(nèi)核質(zhì)量的努力正逐漸成為深受業(yè)界關注的焦點。為了能夠提高驅(qū)動代碼的質(zhì)量，近期Linux基金會也在致力于簡化內(nèi)核任務。然而并不是所有的人都在熱議最好避免bug代碼的方案，要么在系統(tǒng)內(nèi)核開發(fā)之時就盡全力避免此類錯誤保證代碼質(zhì)量，要么就得花費大力氣在出了問題之后亡羊補牢。
Novell公司開放平臺方案研究員Greg Kroah-Hartman向InternetNews.com透露表示，“在協(xié)助上游內(nèi)核開發(fā)人員跟蹤系統(tǒng)問題和修復哪些問題上，Kerneloops 做得非常地不錯。非用戶們提交給kernel組織的信息對于在內(nèi)核開發(fā)階段發(fā)現(xiàn)問題幫助很大”。與此同時，Van de Ven表示希望看到更多的人參與到發(fā)現(xiàn)修復bug的工作上來。
【編輯推薦】
