暫存內容

golang 心得分享

• 剛入門時會接觸到的觀念、術語、關鍵字
  • 了解 GOPATH 的環境參數設定
• golang 有 coding style 校正的機制, 可以用 go fmt 或是 gofmt 指令作校正
• 快速入門可先參考 http://tour.golang.org/#toc 
• 套件的編訪跟配置可參考 https://github.com/astaxie/build-web-application-with-golang/blob/master/ebook/01.2.md
• godep , 可以把專案的相依性固定在特定版本, https://github.com/tools/godep
• golang 關於 dynamic loading 的討論串 https://groups.google.com/forum/#!topic/golang-nuts/zTWTWTwHNxc
• http://www.goinggo.net/2013/08/using-c-dynamic-libraries-in-go-programs.html
• https://github.com/rainycape/dl

docker 心得分享

• Engine 跟 Engine.Job 是 docker 核心類別
  •  特別注意 Engine.Register(<cmd>, <handler>) 跟 Engine.Job(<cmd>).Run() 的用法
  •  可參考 engine/job_test.go 的 sample code

API daemon 的運作概要

• api server daemon 如何產生
  •  docker/docker.go 的 main() 執行 mainDaemon()
  •  docker/daemon.go 的 mainDaemon() ，用 eng.Job("serveapi",...) 呼叫 serveapi 指令，並用 job.Run() 執行之
  •  "serveapi" 指令，會對應執行 ServeApi() 函式
  •  api/server/server.go 的 ServeApi() 接著執行 ListenAndServe()
  •  api/server/server.go 的 ListenAndServe() 執行
    •  httpSrv := http.Server{Addr: addr, Handler: r} 指定 request 的 hander , 其中 handler 由 createRouter() 產生
    •  httpSrv.Serve() 進入 http server daemon 的運行迴圈
  • 
    
•  server 處理 client 發的 request 並回傳 response 的過程
  •  request 會被配發給 http server daemon 所註冊的 handler 處理
  •  這個 handler 由 api/server/server.go 中 createRouter() 所產生
•  server 端，如何分派 request 來的 command 並對應 handler
  •  api/server/server.go 的 createRouter() 所產生 handler ，內有 command 與 registed handler 的對應表( GET/POST/...)
  •  對應的 registed handler 定義在 api/server/server.go 中
    •  大部份  registed handler 會進一步執行 Engine 定義的功能指令
      •  Engine 定義的功能指令，主要位於 daemon/*.go 的目錄檔案中
      •  這些功能指令經由 daemon/daemon.go 的 Install() 中的對應表來註冊成功能指令

sysd 開發生存手冊

• 生存法則1: 先不要管 golang 怎麼寫，矇著眼睛都先 build 過了再說
• 生存法則2: 看不懂主程式，也不會寫 golang, 還是可以新增一個 hello world 模組
• 生存法則3: 有樣學樣，看其他模組怎麼活下來的，我就照著作

• 安裝 go ( 請至 http://golang.org/doc/install 直接安裝軟體, osx, windows, 都有 binary 版本, 不用自己 build )
• 下載 sysd 程式碼 ( 請至本 github 自行找到 git clone 連結 )
• 承2. 下載後，請執行 git checkout -b devel 下載目前的開發版本
• 執行 make.sh 指令 ( 若有安裝 make 工具，也可以直接打 make )
• done ( 若有 build fail 的話, 歡迎 FB 戳一下目前 active 的開發者 )

註1: 執行 ./sysd/sysd ，然後打開 "http://127.0.0.1:8080/ifconfig" 就可以看到輸出的結果. 

註2: 目前主版本在 linux/osx/windows 上都可以 pass build, 歡迎大家下載測試

假設模組名稱為 xyz

• 複製 /mods/sample/ 目錄至 /mods/xyz/
• 將 /mods/syz/ 的檔案名都改為 xyz ( ex: sample.go => xyz.go )
• 編輯 /mods/xyz/xyz.go ，將 "sample" 所有字串都替換為 "xyz"
• 編輯 /mods/loader/mods.go ，比照前幾行，新增一行 xyz 的 => _ "github.com/hacking-thursday/sysd/mods/sample"
• 重複跑一次 make.sh
• 執行 ./sysd/sysd ，然後用瀏覽器打開 "http://127.0.0.1:8080/sample" 就可以看到新增的 xyz 模組的輸出了.

目標指令集

實際遇到過的問題

• http://blog.csdn.net/sumousguo/article/details/20128159
• GoogleCloudPlatform/kubernetes#1469

History: 

2014-10-02 於 H4 下課後，Mat 和 Carl Su, yan 聊天提出構想, 由 Carl Su 建議命名為 sysd.

2014-10-03 於 github.com 作 init commit.

版本號碼我先初步編上去了, 主要變更如下: 

0.0.1 => pass build 

0.0.3 => 可執行的概念驗證 

0.1.0 => 新增模組的架構 

0.2.0 => kd, mat 兩分支成果整合 

0.3.0 => 新增 embed web UI 

0.4.0 => 取得著作授權合作

0.5.0 => 新增套件發佈流程

專案構想起源 , 2014-10-03

( todo: 取精要內容進 "what is sysd" 的介紹內容 )

補充一下, 

這個是昨天下課後聊到的專案，"sysd" 的命名由 Carl.Su 建議

目標是提供一個 api daemon for linux, 可以讓應用程式，透過 Restful API 的方式，來取得系統面的資訊跟操作. 

具體一點，就是我們遇到應用程式要取用 ip 資訊時，通常都是透過像是 system() 的函式操作 ifconfig 的方式來取得. (ex: http://stackoverflow.com/questions/6147193/output-from-subprocess-popen ) ，所以不管是 php/python/c/javascript... 都會有相同的困擾  =>  1. 必須要有 ifconfig (相依性)  2. 要 "parsing" ifconfig 的輸出訊息 ( F**K!! )

但細看 ifconfig / route /.. 的實作，其實就只是一些 ioctl 呼叫 kernel API , 跟 cli 的 cmdline 操作的搭配而已. 所以我所想的就是: 

如  果今天把一系列類似 output = os.system("ifconfig eth0") 都換成通用的 API  =>   rest_api.get( "/sysd/ifconfig/eth0" ) ，並回傳 json/xml   容易處理的格式，那會帶來什麼樣的改變呢!?

上述的這個想法，就是 sysd 這個專案的源始動機. 

實作面上，預計比照 docker 的架構，只是將對象從 vm 的操作換成 Linux 系統資訊 ( ex: uname, arp, route, /sys/* )

有興趣的人，可以先 checkout docker 的 source code, 建議可先看 /api/server.go 的 createRouter() 跟 /api/client.go 的 CmdInfo() 開頭.  

另外提供之前的讀碼筆記作參考,  http://www.hackingthursday.org/2014-03-13#toc4

目前什麼成果都還沒有，所以我想前期 3~4 週, 可能會像 3~5 人的興趣小組讀書會 ( linux + api + go )  , 等到開始有可 demo 的 prototype 時，再更公開 promote 給大家一起參與~

any question? welcome feedback

Linux /proc, /sys 研究心得

( todo: 取精要內容進 "Developer Guide" 的架構介紹內容 )

跟大家分享一下最近的 survey 心得.

1.  我發現 /proc/ 跟 /sys/ 下的資料，主要有幾種大類別 A => 像 /proc/cpuinfo , 左欄 Key  + 右欄  value B => 像 /proc/net/route, 第一行是 key columns, 第二行之後是 values C  => 像 /proc/loadavg , 一行資料，以空白分隔 D => 像 /proc/softirqs , 屬於 table  式的 若針對上述 4 種類別寫出通用的函式，parse 成 2維陣列，應該能快速支援不少資料         

2.  另外 我發現  /sys/ 目錄有一些規則, 只有 /sys/devices/ 目錄有龐大的樹狀結構。剩下的 /sys/*/  其他目錄，大都只有 1~2  層的結構. 所以我猜測, /sys/*/ 的其他目錄，應該是屬於分類class性質的，而  /sys/devices/ 底下，則是真正的  object tree. 

3. 承上, 我發現每個 object node 都有 "uevent" 的檔案，所以似乎可以用 ` find /sys/devices/ -type f -name ’uevent’` 來列舉所有的 device object.

4. 承上，我注意到有些目錄會有 subsystem 或 driver 的 symbolic link.  我認為用這個連結關係來回溯分析，應該可以分析並繪出  device object tree 跟 driver / subsystem 的關連圖.

具體一點來說，大概就可以產出像是  http://i.stack.imgur.com/LMa7A.pnghttp://www.dannytsang.co.uk/wp-content/uploads/2010/02/Device-Manager.png 的成果圖表. ( HTML UI? )

5. 以 cpufreq-info 為例 

一 開始找的 /sys/devices/system/cpu/cpu0/cpufreq/* 並沒有 uevent, 所以不是 device  object. 是上一層  => /sys/devices/system/cpu/cpu0/ 有 "subsystem" 的 link 到  /sys/bus/cpu/ => /sys/bus/cpu/ 有 devices/ 跟 drivers/ 目錄，分別列出 device  object 跟  driver 的項目. 不過此例因為 cpu 是 kernel built-in 的功能，所以沒有 drivers/*  的內容. 

6. /sys/ 下的資料，比較多是 device based 的資料集比較多，所以這部份要一個一個去查每個 subsystem 的特性，才會轉譯整合成 API. 

BTW, 不知道有沒有人知道那裡可以查到 driver 相關的 kernel API 資訊??