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