月: 2013年5月

FreeBSD でデバイスドライバ書いて DMA を動かすためのいろいろ。とりあえず参考になりそうなのは、

• FreeBSD Architecture Handbook: Bus Memory Mapping
• bus_dma (9)
• Writing and Adapting Device Drivers for FreeBSD
• How to write a device driver in FreeBSD (PDF)

このあたり。実例は /usr/src/sys/dev の下あたりをみればいくらでもあるけれど、とりあえず参考にしたのは /usr/src/sys/dev/hifn/hifn7751.c とか。
bus_alloc_resources() とかで BAR の値を読み出したり、DMAC を制御するためのレジスタを mmap() できるようにするあたりは今回はとりあえず省略して、DMA のアクセス先になるメインメモリ上の領域を確保するための手順をまとめておくことにします。

1. bus_dma_tag_create()
   デバイスのDMACに関するいろいろを設定する。たとえば以下のようなこと。これを DMA tag という。
   • 何バイト単位でDMAできるか(1バイト単位か、4バイト単位か、など)
   • DMA可能なアドレスの範囲 (16MB, 4GB, それ以上、など)
   • DMA用のメモリの合計の最大サイズ
   • 上記メモリを最大いくつのセグメントに分割してよいか、セグメントサイズの上限はいくらか

   DMA tag を作るだけではメモリは確保されません。

2. bus_dmamap_create()
   タグの情報に基づいて map を生成します。ひとつのタグに対応する複数の map を生成できます。map だけで、実際のメモリは確保されないっぽい。

3. bus_dmamem_alloc()
   ここでmalloc() か contigmalloc() (確保する領域のサイズ次第ですね) が呼ばれます。確保されるサイズは tag を作るときに指定した最大サイズ。物理アドレスは分散している可能性がありますが、カーネル仮想アドレス空間では連続した領域になります (たぶん)。

4. bus_dmamap_load()
   最後にこれでデバイス側から見えるアドレスのリストを受け取ります。bus_dmamap_load() ではすぐにリストがもらえなくて、callback 関数を指定しておいて、おわると結果が帰ってくる感じです。

片付けるときは逆順です。

1. bus_dmamap_unload()
2. bus_dmamem_free()
3. bus_dmamp_destroy()
4. bus_dma_tag_destroy()

ICFPT Design Competition の委員をやっているので、ホストになるコードをごりごり書いているわけですが、GTK とか Qt とかでユーザインタフェイス作るのだるいなー、と思って HTML+JavaScript でやることにしまいた。最近は nmny 作ったりしてけっこう JavaScript 書いてた (きれいなコードじゃないと怒られそうですが) ので、まあいけるかなー、と。
ブラウザで表示させる部分から AJAX でデータを取りにいけばいいわけですが、そうすると何が問題かというと、HTTP のところを自分で書かないといけないところです。今回の場合、会場でプロジェクタに接続するマシン一台だけで見られればいいので、複数のブラウザから同時にセッションを張られることは考えていません。
なんとかわりとちゃんと動くようになったのですが、引っかかったポイントを記録しておきます。なにしろ、MPI とかじゃなくて、直接 TCP で通信するプログラムをまともに書くのは、自分が学生だったときの学生実験以来なので…

Address already in use

デバッグ中はプログラムを走らせて止めて、修正してはすぐ起動するわけですが、すぐ同じポートを使うプログラムを走らせると Address already in use になって bind() できないことがあります。
これは、ソケットが close されてもしばらく再利用できないため (再利用できるまでの時間はTCP/IP stackの実装依存っぽい) で、setsockopt() を使って解決します。FreeBSD/MacOS X では SO_REUSEPORT も指定しますが、Linux では SO_REUSEADDR だけで動くみたい、というか、SO_REUSEPORT がありませんでした。
[code:cpp]
  setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, (char*)&on, sizeof(on));
#if defined (__FreeBSD__)  || (__APPLE__)
  setsockopt(sock, SOL_SOCKET, SO_REUSEPORT, (char*)&on, sizeof(on));
#endif
[/code]

ブラウザへデータを送信するタイミング

いまのところ複数のクライアントから接続されることはないので、何回目のアクセスではこれを返す、というのが静的に決まっています。そこで、accept() で接続が成立したらすぐにブラウザにデータを送信すればいいや、と思ったのですが、ブラウザによってはブラウザがリクエストを送信するまえにデータが届くとエラーになるようです。
ちゃんと GET がくるまで待ちましょう。あたりまえか…

Socket を close() する前に

BSD 系のシステムでは問題が起きなかったのですが、Linux ではデータがブラウザ側に届く前に、サーバ側から RST が送信されて接続が切れてしまう問題がおきました (これは最初全然わからなくて、wireshark で通信の様子をのぞいてみてはじめて気づきました)。RST が突然送られるので、ブラウザにどこまでデータが送れるかは、毎回違う感じです。
最初は socket を fdopen() して fgets() や fprintf() でアクセスするのが悪いのかな、と思って、最後に fflush() してみたりしたのですが、状況は改善しません。それで、まじめに send() と recv() を使うようにもしてみましたが、やはりうまく動作しません。
で、いろいろ調べた結果、受信バッファにデータが残った状態で socket を close() すると RST が送信されるということがわかりました。つまり、GET がきただけで返事を送っていたのですが、最後の空行まで受信してから返事をすれば OK ということです。
受信バッファが空でないと close() のときに RST が送信されるという挙動、もしかしたら Linux だけなのかもしれませんが、気をつけないといけませんね。

研究室も早いもので3年目。
昨年度のはじめに学生用の端末なんかは充分な台数を確保したので、次はCADとかの環境だよなー、とか、前職の頃から使っているNASもバックアップがないしストレージもいるよなー、と思ったりしています。
去年、Netgear の GS716T というスマートスイッチを購入したときに、16ポートなのにLink aggregation group (LAG) が2本しか設定できないのでびっくりしました。で、ちょっと調べてみたところ、
GS716Tv2: 2 LAGs
GS724Tv3: 4 LAGs
だそうな。うちは教員研究室が機器室も兼ねているので、ファンレスなのが非常にありがたいのだけれど、ちょっとね…
というわけで全前職時代に Myrinet-10G とかでさんざんお世話になった Procurve のラインナップをみてみると、
HP Procurve 1810-24G: 8 LAGs up to 4 links/LAG
これかな。しかし、普及価格帯の managed switch って安くなりましたね…