三不五時， 愛要即時

就這麼一個禮拜， 從此天人永隔
很後悔上個禮拜老爸要我打電話跟妳聊聊天的時候我沒有打
沒想到這一通電話沒打
從此就再也沒辦法跟妳講到話了.....


外婆我會永遠思念妳
祝妳在天國可以幸福快樂..... :' )

Bochs設定方式

這幾天在看《Orange's 一個作業系統的實現》這本書
書中介紹到Bochs這套IA-32的模擬器
但書中所附的設定檔跟我目前在Ubuntu中所使用的設定檔有點不同

C Struct Hack - Structure with variable length array

前些日子在書上看到一種很特別的structure：

C和組合語言對於組語符號引用的差異 (ARM & x86)

之前在trace U-Boot source codes的時候發現了C對於組語內符號的引用方式非常奇特
搜尋了一下相關的資料發現也有人有跟我一樣的疑問

U-Boot中的board_init_f()：
(定義在：arch/arm/lib/board.c)

Linux Kernel: ARRAY_SIZE()

通常我們在C語言中取得陣列的元數個數可以透過下列的方式來計算：

Linux Kernel: BUILD_BUG_ON_ZERO() / BUILD_BUG_ON_NULL()

之前在trace Linux Kernel source codes時發現了兩個很特別的macro：BUILD_BUG_ON_ZERO() 和 BUILD_BUG_ON_NULL()
(定義在：include/linux/kernel.h)
它們的定義如下：

最近看的一些書

這幾個月利用下班後和這個月比較空閒的時間翻了幾本書：

《《超強圖解》前進 Android Market！Google Android SDK 實戰演練, 2/e (適用2.X/3.X/4.X)》

《iOS 創意程式設計家─ iPhone + iPad 跨平台通用, 3/e》

Linux Kernel: __lookup_processor_type

最近在trace Linux Kernel的bootup流程
過程中也發現了assembly與linker script之間的有趣"交流"
特別記錄一下.....
以下的code將以Linux 3.3.4的版本做說明

Never Ends...

最近為了畢業論文花了兩個禮拜左右的時間
研究關於Linux Performance Monitoring的相關技術
從原本完全不知道如何做Performance的Monitoring
到發現原來有不少Open Sourced的Performance Monitoring的Tools
像是：SystemTap、LTTng、Ftrace等工具...
以及其底層所實做的技術：Kprobes、Tracepoints、Ptrace...等

在試過幾個不同的技術後
最後決定Kernel Space Tracing
使用Performance Overhead較高 (因為需要插入Breakpoint instructions)
但可以在不更動所欲偵測程式的source code的情況下做Dynamic Analysis的Kprobes

而User Space Tracing則打算使用GNU GDB底層所使用的Ptrace
(原本打算使用Ptrace的增進版 - Utrace，不過由於尚未支援ARM平台所以只好作罷...)

另外為了能讓資料由Kernel Space pass到User Space的Overhead降到最低
所以還稍微研究了Relay (前身為Relayfs)

以及為了提供nanosecond等級的時間精準度
所打算使用的hrtimer (High Resolution Timer)

但人算不如天算...
原先想說大概基本所需要技術都研究的差不多了
剩下的就是跟老師討論實做在我們3D Chip平台上所需的細節後
就可以真正開始設計這套系統...

結果沒想到今天在報告關於Kprobes的進度後
老師又丟了一個新的議題要我解決：
算出Process Context Switch所花的時間
啊吼... 這下真的是在我頭上投下了一個超大顆的震撼彈!!
(難不成是要我去修改Linux Kernel的Scheduler?! 囧rz)
因為不管是Kprobes或是Ptrace...
其原理都是在fucntion的entry或是exit處甚至是function內部再加上int 3的assembly code
(x86、x86_64平台上的breakpoint instruction，也就是soft interrupt)
在對CPU發出soft interrupt後再將控制權轉交給其他的handlers
如此就可以透過此方法來計算function enter及return的timestamps
進而計算出function所花的執行時間，達到Performance Monitoring的功能
但由於Context Switch發生的時間點完全無法預測
因此也無法得知需要在哪個部位下breakpoints

原本是想找理由"婉拒"的
但沒想到老師搬出Linux的time程式
說可以測量出real、user、sys這三種時間

我之前就記得這個程式也只是單純計算程式在User Space及Kernel Space的執行時間
並沒有特別將Context Switch的時間給計算出來...
但因為討論的當下並沒有明確的證據可以證明
老師又很堅持他的論點，所以只好妥協... QQ

果然之後查了user就是程式在User Space所執行的時間
sys就是程式在Kernel Space所執行的時間
而且時間精準度只有second等級 (頂多到millisecond...)
底層實做方法則是透過wait3() system call來實做的
雖然沒有很仔細的好好trace過time的source code
但感覺起來用Kprobes、Ptrace所算出來的時間可能還更精準一點?!


不過有個好消息是我有可能不用作硬體整合
可以專心開發Performance Monitoring Tool了!! (喔耶~ \(●口●)/)
但看來Context Switch的問題勢必是會被要求得解決了?! QQ
目前查了一些資料 是的確有計算Context Switch的Benchmark
(像是：LMbench)
不過還不知道其底層所實做的方法為何就是...
(倒是覺得自己越來越像是在OS Lab了... XDDD)

目前還有另外一個隱憂就是目前測試都是在x86的平台上做的
天曉得移植到板子的ARM平台後又會發生啥鬼事情?!
還有root filesystem若有缺少所需使用的Library可能也得自行想辦法加入... QQ


果然就如同學長所說的
若是他能預測老師的想法他早就畢業了...

這次報告前完全沒想到會有Context Switch相關的問題要解決
沒想到老師還是給它揪了出來!!
老師的想法果真是很難預測..... QQ

就連才要在台灣待兩個月的德國佬今天也被我們老師assign工作要做了
原本以為兩個月的時間應該光瞭解一些基礎知識就差不多要回國哩
但老師還是assign他要用SystemC做一個Flash Memory版的cache
甚至還要求能轉換成RTL下到FPGA上
(不過我想這點時間能完成SystemC modules大概就很不錯了...)

實驗室真的是越來越"強大"了!! <囧>

Recently...

唸研究所滿一年了...
馬上也就要碩一升碩二了~
時間過得真快...
也體會了不少黑暗學術界的辛酸血淚... QQ

當初進研究所的時候是想要專心研究Embedded Linux的
雖然還是有做到Device Driver相關的Maintenance
不過最後還是被老闆抓去做硬體整合... Orz

能有機會學到以前輔大不太常碰到的硬體是個還蠻難得的機會
而且軟體寫久了也會想瞭解一下最底層的硬體是怎樣在運作的
不過整合最討厭的就是得先等到別人開發到一定的程度後才能開始工作
(就某方面來說這也很像Device Driver的開發
必須等到軟/硬體都有一定的程度侯才能驗證自己寫的是否正確無誤... QQ)
再加上設計者不是自己
因此只能單純就Bus上的行為來觀察IP是否正常運作
沒問題的話倒還好...
機車的就是當問題發生的時候常常不知道為啥會出錯!!!!!
有可能是我們自己整合的時候有修改到錯的地方
也有可能是他們本身設計上的錯誤...
雖然目前主要還是學長在處理這方面的問題
不過看了真的是覺得沒啥勁.....
而且之後還要把我們實驗室的CPU和ICE一起給整進去
最後還要能Tape out成一顆晶片回來!!
(聽說光排隊等Tape out就要一、兩個月?! QQ)
一想到就整個頭很大..................... <囧>

原本以為自己碩士畢業論文大概就是跟軟/硬體整合相關的了
沒想到上週老闆又提起了當初他所提的軟/硬體效能監測工具的東西出來
這次再被提就真的是逃不掉了...
硬著頭皮就是得給它做出來才行!!

一開始對軟體的效能監測一直都沒啥頭緒
只知道用最簡單的printf()或是printk()來印出所執行的時間
但這些function calls本身的overhead就非常重
而且若想要移植到新的應用程式就得重新寫過
對效能和可移植性來說都是非常不好的方法

再加上在有OS的情況下因為OS Scheduler的關係...
要針對各個應用程式來監測便變得更加的困難
因此勢必得從Kernel層本身來下手

在書上無意間看到了LTTng (Linux Trace Toolkit Next Generation) 這套工具
查了以後才發現這是套非常強大的Open-Sourced的軟體
不但可以針對Kernel Space及User Space來監測其效能
甚至還提供了LTTV (LTTng Viewer) 這套GUI介面的軟體來分析其所擷取的效能分析結果
而且最棒的是作者在他的官方網頁上都有放他所投出去的Papers和Presentations
連他自己的博士論文都完整的放在網頁上供人點閱
也就此瞭解到了不少Kernel Source本身
或是別人release的Kernel Patches來協助完成tracing / debugging的功能
像是：
GNU GDB和strace所使用的ptrace() system call
Kprobes
LTTng作者：Mathieu Desnoyers (神人!!) 所開發的Kernel Marker和Tracepoints
IBM工程師特別針對Device Driver tracing / debugging的Linux Driver Tracing Interface (DTI)
以及relay (前身為relayfs)

希望在研究後也可以設計出自己一套基本的軟/硬體效能監測的工具!! XDDD

另外Linux Symposium也是一個超棒的研討會
很多Mainline Linux Kernel所包含的技術都有在這研討會上發表過Papers
(還蠻希望未來能有一天可以參加這種研討會的... XDDD)

前兩天還去上了國家晶片研究中心(CIC)開的Bootloader的課程
對程式底層架構、Linker script和U-boot也終於是有了一點概念...
不過ARM的assembly code實在是很不熟!! QQ


雖然還沒開始正式接觸到硬體設計的部份
不過就目前來說還是對Linux Kernel比較有興趣點... >M<"
而且這也比較符合當初進研究所希望做的Linux Kernel相關研究
自己也能比較有自己的進度 不用每次都要等別人修改
(但Overloading也跟著變重很多就是... QQ)


還不曉得最近看的東西是否真的可以用在我們實驗室的平台上
x86或x64平台的支援還是比ARM要完整的多了...
而且我們實驗室用的板子是廠商自己開發的
相對於有Open-Sourced支援的Versatile平台限制可能也會多了不少?!
還是得花時間再研究一下其可行性才行.....


希望這真的是我最後的畢業題目了...
之前做的事情對老師來說真的只是在"練功"
而且就"練功"而言來說還真的是不太好練... <囧>

現在的Overloading已經接近滿載!!
而且還有要帶學弟...etc 的事情要弄
再被assigned其他的東西要做我就真的是要先自爆嚕!!!!! (●皿●)"
另外最重要的當然就是希望能兩年準時畢業啦!! XDDD