ivaneeo's blog自由的力量,自由的生活。 |
1 flavor [ˊfleiv?] n. 特色,風味
1. effect [iˊfekt] n. 結果,影響,效果;
2. environment [inˊvair?nm?nt] n. 環境 3. exert [igˊz??t] v. 發揮,運用 4. existence [igˊzist?ns] n. 存在,實體 5. evolve [iˊv?lv] v. 進化,逐漸發展
1. pattern [ˊp?t?n] n. 模式,模型
2. possibility [p?s?ˊbiliti] n. 可能性,可能的事 3. procedure [pr?ˊsi:d??] n. 程序
1. separate [ˊsep?reit, ˊsep?rit] v. 分開,隔開
2. several [ˊsev?r?l] pron. 幾個 3. spell [spel] n. 符咒,魅力; 4. spirit [ˊspirit] n. 精神,靈魂 5. standalone adj. 獨立的,單獨的,不需要外部的。 6. syntax [ˊsint?ks] n. 語法
1. manipulate [m?ˊnipjuleit] vt. 操縱,操作
2. myriad [ˊmiri?d] n. 萬,無數,無數的人或物
1 hurdle [ˊh??dl] n. 障礙,跳欄,臨時活動籬笆
這篇短小的文檔用于描述linux內核編程中推薦的編程風格。編程風格是很個人 首先,我建議你打印一份GNU代碼風格,不是去讀它,而是把它燒了,這是個很 不廢話了,下面就是Linux內核編程風格: 第一章:縮進 制表符(tabs)占8個字符,所以縮進也是8個字符。有些異端運動想使用4個字符 原因:縮進的根本目的是用來清晰地標識一個控制塊的起始。特別是當你連續盯 現在,有些人提出8字符縮進會使得代碼太偏向右邊,當使用80字符的終端 簡而言之,8字符縮進使得閱讀代碼更為容易,并且在你的縮進層次過深時提出 第二章:括號的位置 括號位置的問題在C編程風格中經常被提出。和縮進大小不同,括號位置的選擇 if (x is true) { we do y } 但是,函數是一種特殊的情況,函數的左括號放在下一行的開始,象這樣: int function(int x) { body of function } 全世界的異端人士指出這種不一致的做法 ...嗯... 注意到右括號完全占有單獨的一行,_除非_當它后面還有未完成的語句,比如do do { body of do-loop } while (condition); 和 if (x == y) { .. } else if (x > y) { ... } else { .... } 原因:K&R。 還有,注意到這種括號的布局方法還減少了空行(或者說是幾乎是空行)的數目, 第三章:命名 C是個斯巴達式(崇尚簡潔風格的)語言,所以你的命名方法也應該如此。與 _但是_,盡管人人都會對大小寫混雜的名字皺眉頭,全局變量名則必須如此。管 _全局_變量(只有在_真正_需要時才使用)需要有個描述性強的名字,這點和全 把函數的類型加入到名字中(所謂的匈牙利命名法)是腦損傷的表現 _局部_變量應該短小扼要。如果你有個隨機的整數循環變量,可能最好叫它“i”。 如果你擔心混淆你的局部變量,那么你就會有另一個問題,所謂的函數膨脹荷爾 第四章:函數 函數應該短小而甜美,而且只能做一件事。他們應該只用一兩屏幕(我們都知道, 函數的最大長度應該與函數的復雜性和縮進層次成反比。所以,如果你有個只有 但是,如果你有一個復雜的函數,你擔心一個中等智力的高一學生可能無法理解, 函數的另一個指標是局部變量的數目,局部變量的數目不應超過5-10個,否則一 第五章:注釋 注釋是好東西,不過存在過分注釋的危險。_永遠_不要在注釋中解釋你的代碼是 一般來說,注釋應該說明代碼在做什么,而不是怎么做。并且,不要把注釋加在 第六章:你的代碼亂七八糟 沒什么,我們都遇到過。你可能從老Unix用戶那里聽說過“GNU 所以,你或者徹底仍掉GNU (defun linux-c-mode () "C mode with adjusted defaults for use with the Linux kernel." (interactive) (c-mode) (c-set-style "K&R") (setq c-basic-offset 8)) 這會定義 M-x linux-c-mode (setq auto-mode-alist (cons '("/usr/src/linux.*/.*\\.[ch]$" . 但是即使你用不了emacs,并不是世界末日:你還可以使用“indent”。 又一次,GNU indent使用了和GNU “indent”有很多選項,特別是注釋布局部分,你可能想看看它的man手冊。但 第七章:配置文件 配置選項 代碼中使用的是3字符縮進,config-選項中應該使用2字符縮進標識依賴關系。 if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then tristate 'Apply nitroglycerine inside the keyboard (DANGEROUS)' if [ "$CONFIG_BOOM" != "n" ]; then bool ' Output nice messages when you explode' CONFIG_CHEER fi fi 一般來說,所有不穩定的選項應該標為CONFIG_EXPERIMENTAL。所有可能損壞數 第八章:數據結構 供多線程使用的數據結構應該采用引用計數(reference 引用計數的使用能避免鎖的使用,使不同的用戶能夠并行使用數據結構 注意到加鎖_不是_引用計數的替代物。加鎖用于保證數據結構的完整性,而引用 一些數據結構可能使用兩層的引用計數,當對不同的“類”都有使用的時候。子 這種“多層引用計數”的例子可以在內存管理代碼(“struct 記住:如果另一個線程能夠看見你的數據結構,而你卻沒有對它使用引用計數, 這是一個不應該有的話題,因為最早沒有選擇,我們只有一臺機器,一個系統,程序設計改變了我們的思想。各種為實現業務所開發的語言用到了OS上,unix就是一個很好的例子 linux在GNU下得到了飛速的發展,通過internet,我們傳播她,他就是一個在虛幻世界出來的惡魔(freeBSD)的兄弟,這次他的對手是windows。和他的兄長相比他的競爭更加復雜化。(bsd與商業unix的之間關系)。 不管你在這場OS大戰中,選擇那方,你都會對計算機感興趣,因為不管是不是自由的狂熱,還是銅臭的金錢,計算機技術仍然會推動這個真實世界的前進。 下面是20世紀短短的10年linux的走過 內核黑客Alan Cox 轉而為小紅帽工作。 SGI 發布基于Linux的服務器1400L, 并與Red Hat 幾個重要的RedHat Linux內核文件介紹 [轉貼 2005-09-30 090534 發表者 fannao_linux] 在網絡中,不少服務器采用的是Linux系統。為了進一步提高服務器的性能,可能需要根據特定的硬件及需求重新編譯Linux內核。編譯Linux內核,需要根據規定的步驟進行,編譯內核過程中涉及到幾個重要的文件。比如對于RedHat 一、vmlinuz 從圖中linuxrc這個腳本的內容可以看到,initrd實現加載一些模塊和安裝文件系統等。 下面的命令創建initrd映象文件: 三、 System.map 在進行程序設計時,會命名一些變量名或函數名之類的符號。Linux內核是一個很復雜的代碼塊,有許許多多的全局符號。 然而,在有的情況下,我們需要知道符號的地址,或者需要知道地址對應的符號。這由符號表來完成,符號表是所有符號連同它們的地址的列表。上圖就是一個內核符號表,由上圖可知變量名checkCPUtype在內核地址c01000a5。 Linux 符號表使用到2個文件: 雖然內核本身并不真正使用System.map,但其它程序比如klogd, lsof和ps等軟件需要一個正確的System.map。 另外少數驅動需要System.map來解析符號,沒有為你當前運行的特定內核創建的System.map它們就不能正常工作。 本人評述:絕對好文!!! 轉自:httpwenwei.blueidea.comarticle.aspid=44 這些日子我一直在寫一個實時操作系統內核,已有小成了,等寫完我會全部公開,希望能夠為國內IT的發展盡自己一份微薄的力量。最近看到很多學生朋友和我當年一樣 一轉眼我在IT行業學習工作已經七年多了,這期間我做過網頁,寫過MIS、數據庫,應用程序,做過通信軟件、硬件驅動、協議棧,到現在做操作系統內核和IC相關 我上的是一個三流的高校,就連同一個城市的人多數都不知道。因為學校不好也就沒有指望能靠學校名氣找一個好工作。所有的希望都寄托在自己的努力上了,大一開學前 大二準備學VC和BC,當時難以取舍,后來選了VC,不為別的,只為書店里兩本書,VC那本便宜6塊錢。我的努力在班上無人能及,學的日夜不分,大三有了計算機 大三假期找了個機會在一個計算機研究所實習,與其說實習不如說是做義工,工作了兩個月一分錢沒有拿。但是這兩個月對我的發展幫助很大,讓我早一步了解了社會,剛 剛走上工作崗位的學生很容易被誤導,各種開發工具讓人眼花繚亂,同時也覺得很受公司器重,但這樣工作永遠是一個低層次的開發者。不要跟我說什么系統分析有多么多 話說遠一些,國內軟件開發行業有一個怪圈,很多人覺得VC > Delphi > 至于有人認為C++ > 這樣干了一年我覺得非常苦悶,做的大多數都是熟練工種的活,個人技術上沒有太多的提高也看不到方向。所以決定離開這個城市去上海,尋求更好的發展,并且打算放棄 由于是全新的行業,我把自己降到了零點,我學的VC、Delphi、數據庫派不上用場,擺在我面前的是嵌入式、協議、信令一些我從未接觸過的知識。我知道我沒有 另外,在這里我要感謝我的ProjectManager,他原來是一個大通信公司的產品經理,對人非常和善,我從他那里學到了很多知識,而且他也給了我許許多多 當然我明白如果我對硬件了解的非常少,沒有哪家IC公司會仁慈到招我這樣一個一竅不通的人來培訓。所以我必須努力打好基礎,學一些相關知識為以后做準備。就像我 技術是相輔相成的,當我的硬件有了一定的進步后,我的軟件設計也有了很大的提高,我可以從更深層次理解問題,我做的接入服務器CPU是Motorola 話說遠一點,我由衷的希望在軟件上做的比較深入的朋友們有機會學學硬件以及其它相關知識,尤其是做底層開發和嵌入式設計的。這對軟件技術的提高有非常大的幫助, 我有一些心得體會與大家分享,只有當我干好本職工作后,我才會學習與工作關系不大的技術,這樣公司的上司才不至于反感,在入門階段的問題我通常不去問那些資深人 我的最終目的是IC而不是PCB,所以我下一步的準備開始學習IC設計的知識。公司的同事沒有懂IC設計的,后面的路又要靠自己了,我買了不少相關的書,在網上 愛因斯坦在63歲時說過"一個人沒有在30歲以前達成科學上的最大成就,那他永遠都不會有。"這句話給了我很大的壓力和震動,我馬上就26歲了,離30只有四年 我現在已經在這家新公司上了一個多月的班,開始非常艱難,現在慢慢適應了。第一個月結束時,Team 現在的公司有自己的操作系統,自己的CPU、DSP和其它芯片,在這里我能學到世界上最先進的技術,我們的設計開發不再完全依賴別人的硬件和系統,這讓我很開心 在后面的兩年里我給自己定下了幾個目標: 一.努力做好本職工作,在工作上得到公司和同事們的認同; 二.努力學習IC硬件設計知識,多向同事請教,并利用一切機會多實踐; 三.實現我的實時操作系統的主要部分,完成TCP/IP協議棧模塊,并免費發布源代碼; 四.和我女朋友結婚并買一套小房子,這是最重要的,因為我明白事業是可以重來的,但是珍貴的感情很難失而復得。 在這里提一下我現在開發的操作系統,它是一個實時嵌入式系統,目前支持以下特性: a.支持時間片輪轉調度和基于優先級調度,最多64個優先級; b.搶占式實時內核; c.為了便于移植,主體用標準C實現; d.匯編代碼非常少,不到100行; e.支持任務管理,各任務有獨立的堆棧; f.進程同步和通信目前完成了Semaphore,Message Queue正在調試; g.實現了定時系統調用; h.可以在windows上仿真調試 我還打算下一步實現優先級反轉保護,Event Flag,Data Pipe,內存管理(以前實現過)、驅動接口等。 在這之后我還會努力完善它,比如加入文件系統,協議棧、調試接口等。希望朋友們提出自己的意見和建議,在此不勝感激! 后記: 就像有的朋友說的,我的經歷或許會給一些朋友產生誤導,在這里我必須說明一下。我來上海以前學習過于拼命,常常晚上只睡3個多小時,我身高1米71,那時只有1 而且我也發現拼命不是辦法,我可以熬一兩個通宵,最多的一次我連續工作了三天三夜,但是我半個月都沒有恢復過來,這樣是不是得不償失?學習工作應該是一個長期的 技術沒有貴賤只分,我以前換行業是因為自己的興趣所致,而不是對哪個行業有什么偏見。我希望我的經歷不要給朋友一個錯誤的導向,覺得我始終向更高的技術發展。其 我是一個自己覺得比較有自知之明的人,或許我最大的優點就是知道自己有很多缺點:)。我的故事中很多的曲折和錯誤都是由我的缺點造成的,希望大家用審慎的眼光看 當然這么些年的學習和工作多多少少有些收獲,下面我說說我的一些學習的心得,這些方法未必正確,我也在不斷探索和改進中。我的學習和工作有相對明確的目標,我不 至于嵌入式開發環境更加容易實現,PC就是一個非常大的硬件平臺,現有的嵌入式操作系統通常都支持X86,你可以在上面做開發,通過軟盤Boot或者使用虛擬機 前段時間處理了很多事情,一直沒有寫下去,花光了所有的積蓄買了一套房子,同時把戶口的事情也基本辦完了,這幾天稍微緩口氣。昨天跟我的一個老上司見面聊了半天 其實很多朋友并不了解我,我不是一個追逐時尚技術的人,我只是不愿意做一個所謂的"白領",更加不愿意做一個單純的"程序員"。我不甘愿平凡的生活一輩子。我在 自負常常伴隨著無知,記得我大學畢業時,論文答辯會上我和專家組組長爭起來了,因為我對自己的設計非常得意,而他雖然是雞蛋里挑骨頭,但是由于知識非常有限,我 從第一個"Hello 下面一段話是我寫程序的座右銘,希望與大家共勉: Make it right before you make it faster. Keep it right when you make it faster. Make it clear before you make it faster. Do not sacrifice clarity for small gains in efficiency. Brian Kernighan Trackback |