procファイルシステムってなに？

ZYBOのチュートリアルを一通り終えた。
/proc/myledデバイスを登録してリードライトが可能になったので、原理的にはハードウェアとの情報のやり取りはなんでも可能ぽぃ。

けど、このサンプルの通りだとアクセスするたびにfcloseしてopenし直さないといけないのでオーバーヘッドがとてもでかいです。

試してみたら

1. fopen
2. fputcでLEDの状態を変更
3. fclose

のセットをを100万回やって2分36秒でした。1回あたり0.23msかかっていることになります。

※後でもう少しちゃんと計りなおしました


ど論外というほど遅くはありませんが、大半がfopen/closeのオーバーヘッドだと思うのでオープンしっぱなしでアクセスしてキャラクタデバイスの限界速度を知っておきたくなります。


というところで、キャラクタデバイスの中でもこのサンプルはprocfsの枠組みを使っているそうなので、procfsについてまずお勉強からです。

http://www.turbolinux.com/solution_service/library/features/c_magazine/vol_03.html


勉強しているうちに、ZYBOのサンプルはprocfsの中でも、さらにseq_fileインターフェイスを使ってバッファリングしていることがわかりました。

http://wiki.bit-hive.com/tomizoo/pg/proc%20fs%20%A4%F2%BB%C8%A4%C3%A4%BF%A5%AB%A1%BC%A5%CD%A5%EB%BE%F0%CA%F3%A4%CE%C9%BD%BC%A8%20%A4%BD%A4%CE2


ZYBOのチュートリアルだとopenの時にseq_printfしてドライバとしてはreadのための処理を終えちゃっていて、後は1バイトずつ読出しがかかるたびにseq_readが受け渡しをやっているようです。

この方式だと、openして、大量のデータをどがーーーっと読み出してcloseするようなある意味ブロックデバイスのようなデータ転送がキャラクタデバイスでも簡単にできそうです。



まあ、それはそれで後で転送速度とか調べるとして、逆にIO監視のようなリアルタイムちびちび再読出しを(毎回のopen/closeオーバーヘッド無しに)するにはどうするか…。seq_fileを使わない方が簡単そうですね。


追記:
seq_fileを使わない方は、create_procの書式が最近変更されていて古い記事がそのまま使えなかったので新書式のほうのサンプルからスタート
http://pointer-overloading.blogspot.in/2013/09/linux-creating-entry-in-proc-file.html