在 Embedded linux 平台上面,
有時會發生頻繁使用 script 而造成系統發生問題 (ex. kernel panic, memory dump)
此時在 debug 的時候如果想要印出一些資訊來觀察,
但又要避免使用 script,
就只好使用 c 來實作,
例如原本以 shell script
date 查詢目前系統時間,
cat /proc/meminfo 查詢目前 LowFree 使用量以及所有記憶體資訊,
就可以用上面的C程式範例來達到與 script 同樣的效果。
2010年12月21日 星期二
linux swap file
/ $dd if=/dev/zero of=/mnt/sd/swapfile bs=1024 count=2970
2970+0 records in
2970+0 records out
在 sd card 建立一個 2.9MB 的 swap
/ $ mkswap /mnt/sd/swapfile
Setting up swapspace version 1, size = 3035136 bytes
/ $ swapon /mnt/sd/swapfile
/ $ free
total used free shared buffers
Mem: 62724 44752 17972 0 20
Swap: 2960 0 2960
查看是否 swap 有配置成功
2970+0 records in
2970+0 records out
在 sd card 建立一個 2.9MB 的 swap
/ $ mkswap /mnt/sd/swapfile
Setting up swapspace version 1, size = 3035136 bytes
/ $ swapon /mnt/sd/swapfile
/ $ free
total used free shared buffers
Mem: 62724 44752 17972 0 20
Swap: 2960 0 2960
查看是否 swap 有配置成功
2010年9月29日 星期三
OOM problem
觀察 /proc/meminfo,
之前在某些專案遇到 Out of memory 的問題,
可以試著察看 Committed_AS 這個欄位,
系統有可能在 OOM 的情況下,
砍掉任一支吃最多ram的程式,
進而導致系統不穩定。
之前在某些專案遇到 Out of memory 的問題,
可以試著察看 Committed_AS 這個欄位,
系統有可能在 OOM 的情況下,
砍掉任一支吃最多ram的程式,
進而導致系統不穩定。
2010年6月8日 星期二
message queue
1. msgQ很像fifo, 但是更有效率。
2. 讓兩個不相關的程序可以傳送資料。
3. 可免除同步化和擱置的問題。
sys/msg.h
sys/types.h
sys/ipc.h
int msgctl(int id, int command, struct msgid_ds *buf):
控制函數 (IPC_STAT, IPC_SET, IPC_RMID)
int msgget(key_t, int msgflg):
產生和存取 msgQ (IPC_CREAT)
int msgrcv(int id, void *msg_ptr, size_t sz, long int msgtype, int msgflg):
從 msgQ 取出訊息
int msgsnd(int id, const void*msg_ptr, size_t sz, int msgflg):
增加一個 msg 至 queue
struct msg {
long int type;
/*the data you wish to transfer*/
char data[MAX_SIZE];
}
第三個參數 sz, 是 msg_ptr 的大小, 但是不包含第一個 long int
第四個參數 msgflg 如果含 IPC_NOWAIT, 則會立即回覆
舉例來說,
如果伺服器與客戶端要溝通,雙方可以各有一個 msgQ,
而如果有很多客戶端,如果使用大量的 msgQ,可能會較浪費;
此時可以試著將第一個 type 欄位拿來記錄客戶端的 ID,
用來區別要送到哪個客戶端;
而每個客戶端也可以抓取屬於他們自己的訊息,
而不會動到其它客戶端的訊息。
2. 讓兩個不相關的程序可以傳送資料。
3. 可免除同步化和擱置的問題。
sys/msg.h
sys/types.h
sys/ipc.h
int msgctl(int id, int command, struct msgid_ds *buf):
控制函數 (IPC_STAT, IPC_SET, IPC_RMID)
int msgget(key_t, int msgflg):
產生和存取 msgQ (IPC_CREAT)
int msgrcv(int id, void *msg_ptr, size_t sz, long int msgtype, int msgflg):
從 msgQ 取出訊息
int msgsnd(int id, const void*msg_ptr, size_t sz, int msgflg):
增加一個 msg 至 queue
struct msg {
long int type;
/*the data you wish to transfer*/
char data[MAX_SIZE];
}
第三個參數 sz, 是 msg_ptr 的大小, 但是不包含第一個 long int
第四個參數 msgflg 如果含 IPC_NOWAIT, 則會立即回覆
舉例來說,
如果伺服器與客戶端要溝通,雙方可以各有一個 msgQ,
而如果有很多客戶端,如果使用大量的 msgQ,可能會較浪費;
此時可以試著將第一個 type 欄位拿來記錄客戶端的 ID,
用來區別要送到哪個客戶端;
而每個客戶端也可以抓取屬於他們自己的訊息,
而不會動到其它客戶端的訊息。
socket programming - select
socket介面其實很像pipe,使用方式很雷同,但是還可以跨越網路通訊。
平常在實作中,常使用無窮迴圈做 busy wait,然後掃描是否有需要處理的事件;
但是這樣的方式較耗費CPU時間。
sys/types.h
sys/time.h
現在,可以試著使用 select() 系統呼叫,
可以同時處理很多檔案描述子(就像是很多客戶端),
但是沒有任何輸入/輸出時,
是處於擱置狀態。
select() 在 fd_set 的結構上運作,
我使用過的例子是設定 socket 為 Non-Block 模式,
然後 select 設定 Timeout 時間,
如果 time out 時間過了仍然沒有任何事件發生需要處理,
select() 也會回覆。
select() 回傳 -1 代表失敗,並會設定errno說明錯誤。
藉由 timeout 的管理,如果發生 time out,select() 會回傳0。
不多說,來看個例子吧!
平常在實作中,常使用無窮迴圈做 busy wait,然後掃描是否有需要處理的事件;
但是這樣的方式較耗費CPU時間。
sys/types.h
sys/time.h
現在,可以試著使用 select() 系統呼叫,
可以同時處理很多檔案描述子(就像是很多客戶端),
但是沒有任何輸入/輸出時,
是處於擱置狀態。
select() 在 fd_set 的結構上運作,
我使用過的例子是設定 socket 為 Non-Block 模式,
然後 select 設定 Timeout 時間,
如果 time out 時間過了仍然沒有任何事件發生需要處理,
select() 也會回覆。
select() 回傳 -1 代表失敗,並會設定errno說明錯誤。
藉由 timeout 的管理,如果發生 time out,select() 會回傳0。
不多說,來看個例子吧!
2010年5月3日 星期一
FIFOs
利用FIFO讓兩個不相關的程式也可以交換資料。
引用
sys/types.h
sys/stat.h
所謂FIFO其實就是檔案,用open, close分別開啟與關閉一個FIFO。
open 必須傳入FIFO的路徑名稱。
FIFO 有 Block, NonBlock 模式可供選擇,依個人需求。
☆ 在 linux 下,process被擱置時是不會消耗 CPU 資源,所以使用 FIFO 時,這樣的同步方式是非常有效率的。
可以試著寫一個 daemon 與 client 利用 FIFO 溝通,
分為 write 與 read (request),
但是 read 的時候,
每個 client 最好能有自己的 FIFO,
以免資料被另一個 client 讀取造成錯誤(NonBlock模式下),
當然如果是 Block 模式就沒有此問題了。
由於 i2c bus 是單工的,
同一時間處理一個 command,
如果有很多 device 要做 i2c read/write,
也可以考慮統一把 i2c 讀寫的動作丟給一個專門負責的 daemon,
一來可以統一介面好維護,
再來是 i2c 的讀寫可以保證同一時間只處理一個,
不用擔心 i2c 仲裁的問題。
引用
sys/types.h
sys/stat.h
所謂FIFO其實就是檔案,用open, close分別開啟與關閉一個FIFO。
open 必須傳入FIFO的路徑名稱。
FIFO 有 Block, NonBlock 模式可供選擇,依個人需求。
☆ 在 linux 下,process被擱置時是不會消耗 CPU 資源,所以使用 FIFO 時,這樣的同步方式是非常有效率的。
可以試著寫一個 daemon 與 client 利用 FIFO 溝通,
分為 write 與 read (request),
但是 read 的時候,
每個 client 最好能有自己的 FIFO,
以免資料被另一個 client 讀取造成錯誤(NonBlock模式下),
當然如果是 Block 模式就沒有此問題了。
由於 i2c bus 是單工的,
同一時間處理一個 command,
如果有很多 device 要做 i2c read/write,
也可以考慮統一把 i2c 讀寫的動作丟給一個專門負責的 daemon,
一來可以統一介面好維護,
再來是 i2c 的讀寫可以保證同一時間只處理一個,
不用擔心 i2c 仲裁的問題。
訂閱:
文章 (Atom)