2011年2月18日 星期五

我想做什麼?What Do I Really Want to Do?

Standard
近來,承蒙一些事業天使(Business Angel)關愛,極為客氣且專程邀我交流意見,長輩們不因我是個年輕小夥子,可能存在著年紀上的宏溝,而難以互相溝通,反之相談甚歡。但研究未來趨勢,研究目前機會,進而相互觸發的火花,卻比不上過程中簡單又普通的一個問句,其當頭棒喝讓我這些日子來不斷自我問之。

你想做什麼?

就是這短短五個字,令我當下訝然失聲,換來多天無法平靜,連睡夢中也在試圖尋一條明確的出路,直到驚醒。

經這麼多年時日蹧蹋,倒也不是心中無腹案,無法當場說得天花亂墜,而是發自內心回應這五個字的,是一個大藍圖,一個難以說明完整的藍圖。確確實實,我相信著心中那一齣對未來的憧景,那一套事先設計過的必經過程。現在的我,沒辦法三言兩語說明清楚,也沒辦法完整交代想成就的大事。只是因為有些事『微不足道』,有些事又大的『虛無飄渺』,而我手上只有一張地圖,貫串頭尾。靡靡道來,不免枯燥無味。

或許不少人會嘲弄,請我多方學習演講技巧、說話技巧、表演技巧,學習將最精華的部份講到別人心崁裡。但別人感興趣的可能只是我計劃中的一小部份,那並不能代表我真心想做,試問如何能夠欺己欺人?再說,我也不是要騙人當『金主』,用不著這樣做了。


革命事業

若真的要下一個總結,描述我想要做的事,那我會說:『革命,革我自己的命。如果要走十一步才能到目標,那我一定不會省掉第一步,也不會直接跳第十步。』

這世界上有太多事不一定是走對的路,多半彎彎曲曲又碰碰撞撞邁向終點,隨著大家起舞,多半也能走到終點,只不過時間也會浪費很多,我只想少做錯事,直接往正確的路走去。但這些所謂未來必定的方向,太直接走去,過程中必定也是眾人所指,在大家眼中你不過就是不循大家規矩的革命份子。


驚天動地的未來

我就是要得到驚天動地的未來,但我不會放棄眼前的現實,你們或許聽過很多突然發光的點子,但也聽過更多被風熄滅的燭火。我寧可多下苦功找遮避,點火不會為風所動。


天使投資人

我並不妄想得到錢就能馬上發光,而是一直在煩腦怎麼把各種資源換成太陽,讓它永續不滅。換句話說,只要能協助我的人,就算出力不出錢,也是我的天使投資人。當然,我也不怕成為自己唯一的天使。


人生不後悔的一次嘗試

我有我想走的路,無論會不會成功,其他人看不看好或能否理解我,唯一試試看的機會就是現在。

2011年2月16日 星期三

撰寫跨平台程式需注意的 I/O 和 Offset 問題

Standard
對於檔案操作,坊間已經有太多 Hello World 程式示範過無數次,往往運用簡單的 lseek() 、read() 和 write() 已滿足大多數需求。但在 ARM 與 x86 架構之間,便有些微妙的差異,讓 Hello World 級的範例程式處處失效。的確,很少人真的動手寫一支程式去處理大型檔案,更少人會將這類程式移植跨平台使用。

若發現原本在 x86 上可正常使用 write()/pwrite() 等方式寫入資料,但交叉編譯(Cross-Compile)至 ARM 後,始終無法如預期讀寫資料,那意味著你可能掉進 offset 的陷阱了。

說起來這問題牽涉到 off_t 變數形態的記憶體使用長度,並可分為三個面向探討『Kernel』、『glibc』、『應用程式(Application)』。理論上 Runtime 時,三方對檔案操作的 offset 定義應該是要一樣,但事實上不然,只有在 x86 平台上比較統一。在 ARM 等這類平台,由於各家廠商在製作 BSP 各自定義,各程式和往往預設使用上不盡相同,更主要原因是因為多數應用程式都是從 x86 移殖過來,和 ARM 平台上 32-bit 的預設處理方式會格格不入。

在 x86 架構上(測試環境為 Debian Sid、 Intel Platform),通常 off_t 被定義為 unsigned long long (無號最長整數),總長度是為 8 Bytes(因長度等同 off64_t,下文將 64-bit 的 off_t 以 off64_t 稱之),在此環境下的 gcc+glibc 會自動使用 off64_t 形態做為 offset 處理參數,當然在編譯程式時也會自動使用相對應的處理函數,實作和定義可參考 unistd.h。

而在 ARM 的環境上,卻不一定如此,在某些平台和 BSP 中,off_t 預設就會被定為 32-bit 長度,會造成一些可能發生的問題。

一個例子,若是有寫過 FUSE(Filesystem in User Space) 程式,並移植到 ARM 的經驗,就有機會發現系統上 off_t 定義的大混亂。起因是 libfuse 使用 off64_t 與 kernel/Application 溝通,但若是系統編譯環境預設使用 off_t,我們寫的 filesystem 程式便會不正常。原因在於 lseek()、write()、pwrite() 和 pread() 系列函數只吃 off_t 而不是 off64_t,但同樣的 code ,此問題不會發生在多數 x86 系統上(因為編譯時預設是使用 off64_t 和 lseek64()、write64()、pwrite64() 和 pread64())。

解決這問題有兩種做法,一種是在編譯代入 D_FILE_OFFSET_BITS=64 或程式中定義 __USE_FILE_OFFSET64,另一種就是將所有 pwrite()/pread() 等函式強制改為 pwrite64()/pread64() 等處理 64-bit offset 的函式。