しまった

kernel

昨晩メモった sleep_on() がどこで定義されているのか失念。
と思ったら kernel/sched.c だった。あと、wake_up はマクロになってて include/linux/wait.h で以下の定義

#define wake_up(x)			__wake_up(x, TASK_UNINTERRUPTIBLE | TASK_INTERRUPTIBLE, 1, NULL)
#define wake_up_nr(x, nr)		__wake_up(x, TASK_UNINTERRUPTIBLE | TASK_INTERRUPTIBLE, nr, NULL)
#define wake_up_all(x)			__wake_up(x, TASK_UNINTERRUPTIBLE | TASK_INTERRUPTIBLE, 0, NULL)

ええと、単純に wake_up じゃ駄目なのかなぁ。current 取っといて云々、なのかなぁ。このあたりは色々試験で確認できそげ。

仕様確認

ええと

デバイスのマイナー番号 2N 個を実装するとき、作成するドライバは N 個の FIFO キュー (N = 4) を実装する。

とある。意味が分からない。(鬱
面倒なので勝手に解釈しちゃれ。mknod で /dev/fifo1000 と /dev/fifo1010 を使うとしたら fifo1000 が書き込み用で fifo1010 が読み込み用。
デバイスファイルを直接 open して云々なのか。

もう少し

結構へろへろ。とりあえず device のメジャー番号の検討が必要。これ、色々試すには面白い課題なのは分かるのですが、知識不足が激し杉。
なんか使い方が逆なので微妙なのだろうか

  • read はドライバが持ってる情報をユーザに渡す
  • write はユーザからもらった情報をデバイスに渡す

という理解で良いのかな。しかし

  • read はプロセスをブロック
  • write ブロックされているプロセスを起こす

なんか微妙。write で受け取ったバッファが巨大だったらどうするんだろ。受け取り可能な領域サイズでコピーして write な current 止め (sleep_on) て read な current を開始 (wake_up) するんだろうか。デフォで read は一旦停止 (sleep_on) するんかな。って誰が write な current を start (wake_up) するんだ??
# 多分自分。

簡単なソレから

実装しつつ試験しつつ、なログが残せれば良いのですが。
しかし殴り書きだな (とほほ
でも簡単な例で言えば

$ cat /dev/fifo1010

しつつ

$ cat >/dev/fifo1000

すれば下側でタイプした文字が上側で出力されるはず。

確かに

デバイスが複数になってくると管理が面倒だな。一つのドライバで複数の fifo を管理するのは色々と微妙ですが題材としては面白そげ。