回顧Trace Linux Kernel Source的一些想法~

gogojesse

之前在這裡貼了一些自己trace linux kernel的一些筆記文，筆記式的
文章難免寫得比較瑣碎，閱讀起來應該比較不容易，尤其逐行trace，
: ]/ t5 j0 n  W; S/ c應該會有人很排斥或是不認同這樣的一種方式，之前曾經看到一些文章
( Q$ N3 j8 N+ h7 T' F甚至會明白地提醒讀者切記不要逐行研究程式碼，要將其觀念記住才是
- c* i; V6 x1 B6 R重點。
) I2 F- m3 P# v' A. w2 |( V  v
  n6 Z4 R6 e( |/ ^' `這邊想針對這樣的論點提一些想法給大家參考，目的不是要訂出一個好
/ @( n4 M# @5 I1 ~) q與壞，其實我覺得兩種方法並不相衝突，而是大家在學習的階段，可以
依照理解程度來做取捨。
" Y' M' {1 U% x
, j5 L4 }4 X! [# _2 q! Q# y以自己的經驗來說，以前一開始囫圇吞棗，試圖去理解書上提到的觀念，
似懂非懂的寄了許多東西，但是往往人家問我：
. `6 {5 L6 S8 l  Y5 G" {/ e『你能夠自己寫出一個OS或是其中一部分功能嗎?』
似乎就變得很心虛，只能告訴對方『我知道它的實作原理』，但是說要
自己要寫，好像就是少了點什麼? 好像懂，但是要怎麼真正的寫出來，
* i: o6 ?6 p2 s! P卻是不怎麼敢肯定。

面對這樣的狀況持續一段時間，讓人真正有自信能夠依樣畫葫蘆弄出個
! M$ E. J# b. y% B- S: k- G什麼東西，卻是在花心思從很基本的instruction set開始K和逐行逐行
+ B/ o- K9 y$ r5 W$ g, W了解之後，才覺得似乎概念和實作有了那麼一點連接。也由於這樣的基
7 }5 \  O( U7 ?; V0 U' D礎，有時候有助於資料不足的狀況下，還能夠經由看程式碼來補足資料
不足的部份，甚至可以用來印證自己的想法。

gogojesse

這樣的說起來多看程式的好處多多囉?
$ y1 n9 Y# L8 ?* {6 d
- |& X  V3 d* i; q5 R. h7 n好像也不盡然，自己的經驗是，看上老半天，一大段雖然每個字都看得懂，
* [- f2 h/ N6 J% |/ D) w6 E2 b但是兜起來就是不曉得他要做啥用? (看英文的時候....恩...好像也是這樣   )
有時回頭翻書，看看觀念，才會發現這一段天書似的程式碼所隱含的意
- n  {- y/ |9 E6 b" Y0 O義，自然就理解了。
% g! Z! J5 _  r8 N' G9 ~' z( ^
! u( K$ ~* w+ R# }所以後來想想要深入kernel source的方式，似乎得要雙管齊下，一邊看
觀念，一邊找出相對應的程式碼出來，最後觀念與觀念之間，必定有一些
9 R0 J2 f+ }3 |, u" z, v4 z很細節的部份沒有被提到，玩家就得自己想辦法將他們串起來，一旦書本
上的觀念可以在實際程式上得到印證，那這樣改天要改寫，也就遊刃有餘。
* y$ E* O! ?% [: Y+ R5 w
( g  w; q  y: L* v! E這邊想特別提到的還是閱讀指令集的重要性，對指令的熟悉，不但對閱讀
3 r: L6 Z1 e7 c( l/ _低階的程式碼有很大的幫助，還對於整個系統演進了解更為透徹。以前會
覺得了解太低階的東西用處不大，後來才覺得這些部分有時卻影響很大。
5 C) S5 w9 X" z2 H4 r& N
: w4 n2 e3 M! Q) i以上無聊閒談，歡迎大家提出自己的經驗，交流一下~