Mac用USBデバイス-9 ホスト側のモデル [Mac用USBデバイス工作]
前回まででUSBのバスプロトコルとホストから見たデバイスのプログラミングモデルのおさらいはだいだいできた。USB2.0固有の問題もあるけど1.1がわかればパラメータの違いだけで基本的には問題ないはず。今日からホスト側のプログラミングモデルを整理する。これはOSごとに違うのでMacOS Xの場合に限る。
MacOS XのUSBプログラミングを考える前に、昔のunixのスタイルを思い出してみる。このやりかたはMacOS Xでも通用する。
僕のiMacの/devディレクトリを見てみると
物理的なデバイス、例えばキャラクタ端末(と言っても最近の人はわからないかもしれないけど)やハードディスクなどを表すデバイスファイルもあれば、(僕が他人事とは思えない)/dev/nullや名前付きパイプのような抽象的なデバイス(疑似デバイスとも言う)もある。デバイスファイルにはメジャー番号とマイナー番号がふられていて、それを使ってデバイスドライバを選択することになっている。
unixの場合、デバイスドライバは階層化されていないので、たとえばPCIバスにUSBのホストコントローラとATAのバスが繋がっている場合、PCIをアクセスするコードが両方のドライバに含まれてしまうようなことも起こりえる。このときPCIへのアクセスに対する排他制御はドライバのプログラマの責任になる。
さらにunixのデバイスドライバは、開発が非常に難しい。kernelごとにいろいろなスタイルがあるらしいが、たいていkernelが期待する動作を行うデバイスドライバ内のいろいろな関数を書くことになる。厳密に仕様通りの動作をしないとkernelをクラッシュさせるのでその仕様を熟知していないと書けない。user spaceのアプリなら全然問題にならない引数でのバッファのサイズやメモリの解放のタイミングやスタックの使い方などちょっとでも仕様からはずれるとkernelをクラッシュさせることがある。もちろんこれらはkernelプログラミングではよく問題になるけどunixのデバイスドライバは特に制限の多い部類に入る。
また、デバイスファイルは基本的にはスタティックなものでUSBのホットプラグのような動作に対応することは難しい(USBのデバイスが引き抜かれたことは読み込みが失敗するのでわかるが、つながれたことを検出する手段はない)。
昔、unixのハードウェアはチップが並んだ1枚のマザーボードではなく、CPU、メモリ、SCSIコントローラ、シリアルI/Oなどそれぞれが1枚のボードであり、それがバックプレーンと呼ばれるバスに刺さっていた。ハードウェアの構成を変更するということはそのボードを抜き差しすることであって、それがダイナミックに変化するなどということは考えられなかった。
MacOS Xではunixのデバイスファイルをサポートしながらその下のレイヤにもう少し、デバイスごとの特徴に柔軟に対応するためのメカニズムが用意されている。つぎにそこんとこをもう少し突っ込む。
MacOS XのUSBプログラミングを考える前に、昔のunixのスタイルを思い出してみる。このやりかたはMacOS Xでも通用する。
unixのデバイスファイル
一般のデバイスをアプリケーションから使う場合、unixでは伝統的にデバイスファイルというのを経由する。デバイスファイルは/devディレクトリにあるデバイスを抽象化したスペシャルファイルで、普通のファイルと同じように読み書きすることでデバイスにアクセスする。これは非常にシンプルな発想でプログラミングにとって負担が少ない。僕のiMacの/devディレクトリを見てみると
% ls -l /dev total 4 crw------- 1 root wheel 10, 0 10 2 16:26 autofs crw------- 1 root wheel 13, 0 10 2 16:26 autofs_control crw-rw-rw- 1 root wheel 11, 4 10 2 16:26 autofs_nowait crw------- 1 root wheel 23, 0 10 5 11:00 bpf0 crw------- 1 root wheel 23, 1 10 2 16:25 bpf1 crw------- 1 root wheel 23, 2 10 2 16:25 bpf2 crw------- 1 root wheel 23, 3 10 2 16:25 bpf3 crw-rw-rw- 1 root wheel 9, 1 10 2 16:26 cu.modem brw-r----- 1 root operator 14, 0 10 2 16:25 disk0 brw-r----- 1 root operator 14, 5 10 2 16:25 disk0s1 ....などと並んでいる。
物理的なデバイス、例えばキャラクタ端末(と言っても最近の人はわからないかもしれないけど)やハードディスクなどを表すデバイスファイルもあれば、(僕が他人事とは思えない)/dev/nullや名前付きパイプのような抽象的なデバイス(疑似デバイスとも言う)もある。デバイスファイルにはメジャー番号とマイナー番号がふられていて、それを使ってデバイスドライバを選択することになっている。
デバイスファイルの限界
しかし、デバイス固有の情報や設定にアクセスするためにはファイルに対する読み書きだけでは限界がある。そのために特別なシステムコールが用意されている。一番一般的なのはioctl()コールだろう。しかし当然デバイスごとに設定できる内容が違うのでioctl()の呼び方もそれぞれ異なる。複雑なデバイスになると非常にわかりにくいものになるし、そもそもデバイスをファイルとみなすことに限界が出ることもあり得る。unixの場合、デバイスドライバは階層化されていないので、たとえばPCIバスにUSBのホストコントローラとATAのバスが繋がっている場合、PCIをアクセスするコードが両方のドライバに含まれてしまうようなことも起こりえる。このときPCIへのアクセスに対する排他制御はドライバのプログラマの責任になる。
さらにunixのデバイスドライバは、開発が非常に難しい。kernelごとにいろいろなスタイルがあるらしいが、たいていkernelが期待する動作を行うデバイスドライバ内のいろいろな関数を書くことになる。厳密に仕様通りの動作をしないとkernelをクラッシュさせるのでその仕様を熟知していないと書けない。user spaceのアプリなら全然問題にならない引数でのバッファのサイズやメモリの解放のタイミングやスタックの使い方などちょっとでも仕様からはずれるとkernelをクラッシュさせることがある。もちろんこれらはkernelプログラミングではよく問題になるけどunixのデバイスドライバは特に制限の多い部類に入る。
また、デバイスファイルは基本的にはスタティックなものでUSBのホットプラグのような動作に対応することは難しい(USBのデバイスが引き抜かれたことは読み込みが失敗するのでわかるが、つながれたことを検出する手段はない)。
昔、unixのハードウェアはチップが並んだ1枚のマザーボードではなく、CPU、メモリ、SCSIコントローラ、シリアルI/Oなどそれぞれが1枚のボードであり、それがバックプレーンと呼ばれるバスに刺さっていた。ハードウェアの構成を変更するということはそのボードを抜き差しすることであって、それがダイナミックに変化するなどということは考えられなかった。
MacOS Xではunixのデバイスファイルをサポートしながらその下のレイヤにもう少し、デバイスごとの特徴に柔軟に対応するためのメカニズムが用意されている。つぎにそこんとこをもう少し突っ込む。
2009-11-19 22:23
nice!(0)
コメント(14)
トラックバック(0)
ただいま~!
って何も言ってませんでしたがイタリアに旅行してきました。
8日間に旅行でしたが帰国後疲れて寝込みました・・・。涙。
で、久しぶりにPC触ってます。
by なっちゃん (2009-11-24 17:11)
ただいま~!
って何も言ってませんでしたがイタリアに旅行してきました。
8日間にの旅行でしたが帰国後疲れて寝込みました・・・。涙。
で、久しぶりにPC触ってます。
by なっちゃん (2009-11-24 17:12)
ごめんなさい。
コメント投稿に失敗しましたという画面が出たので
もう一度送信してしまいました。
すんません・・・・。
by なっちゃん (2009-11-24 17:14)
コメントありがとうございます。
な、なんと優雅な。イタリアと言えば、仙台とは時差8時間。仙台だけではないか。
イタリアと言えば、デブのソプラノが叫ぶイタリアオペラと体育会系の脳味噌筋肉ロックしか知りません。行ったこと無いし。
いかがでした?
by decafish (2009-11-24 22:40)
オペラも聴きたかったんですがどうやら夏場に主に上演されるらしく
今の時期はクラシックバレエでした。
残念。
翻訳の話を読んでいて知っていたら教えてもらいたいと思ったんですが、今回イタリアに行くにあたっていろいろネットの翻訳機能を使って文章を翻訳していったのですが、向こうでいざ使おうと思ったところカナがふっていないので読み方が分らずあまり役に立たなかったんです。ついでにバチカンでツアーから置いていかれたり、ヴェネツィアでは電車が遅れて、結局2時間後に出発する別の電車にチケットを窓口で交換しなくちゃいけなかったりと珍道中を繰り広げてきたのであります。で、思ったのが翻訳で読み仮名も出るのなら使えるのになぁと探しています。電子辞書では思ったように訳したいなようにならないようなので、どこかいい翻訳をしてくれるサイトはないもんですかねぇ・・・・?無料だともっとうれしんですが・・・。
by なっちゃん (2009-11-28 16:13)
オペラでデブのソプラノが歌劇場の壁を揺らす(こればっか)のが見られなかったんですか、それは残念です。
珍道中は海外旅行にはつきものですよね。僕もトランクと泣き別れになったり飛行機で目的地と違うところに着いたりしたことがあります。
ところで、イタリア語なら僕は得意です。Allegro ma non troppo un poco maestoso. Adagio molto e cantabile.
楽譜の発想記号ってたいていイタリア語なんですよね。だから形容詞と副詞しか知りません。
機械翻訳のサイトはいくつか知っていますがイタリア語に関してはそう言うレベルなのでいい悪いが全然わかりません。
by decafish (2009-11-30 06:05)
楽譜の発想記号(←発想記号って言うんですね。)ってイタリア語なんですね。翻訳機を買おうかと思ってるんですがインドネシア語が入ってないんですよね。わりと不便っぽいです。
次回旅行する時は対策ねって行きます。笑。
by なっちゃん (2009-11-30 10:38)
今度はインドネシアですか!?
インドネシアには何度か仕事で行きました。結構怖い思いもしましたが、それよりも何を食べても砂糖甘いことのほうがつらかったです。
インドネシア語も食べ物の名前ならいろいろわかります。それ以外は「トリマカシ」しか知りませんが...
by decafish (2009-11-30 22:04)
トリマカシってなんだ?! 笑。
インドネシアは行こう行こうと思って行けないでいるんです。
この前も旅行代金まで支払いしてたのに新型インフルエンザがテレビで大々的に放送されてて、万一帰りに成田あたりで隔離状態になったら責められるなぁ・・・と言う事になってキャンセルしたんです。今の時期って物凄く旅行安いんですよね。この前のイタリアも8日間で10万円でした。という訳で昨日また予約してしまいました。今月の23日から韓国行って来ます。今回は食事、観光付で29,800円仙台発です。キャッホー!
by なっちゃん (2009-12-01 10:15)
なんですと!?
今度は韓国ですか。仙台空港から行けるのですか?韓国には何度も行ったのですが全部仕事だったので釜山近郊の工場のある田舎しか知りません。ソウルなんて行ったことないです。行ってみたい。
ところで、インドネシアでひとに「トリマカシ」というと、小柄な彼らはみんなニコニコと愛想良くしてくれたので覚えましたが、どういう意味だか知りません。バカな日本人が調子いいことを言ってると笑っていただけかも知れませんが...
by decafish (2009-12-01 21:42)
ずーっとこの場所からコメントですみません。
韓国は東京からなら12000円くらいから出てますよ。
今回私が行くのは仙台発です。
交通機関の金額を考えても仙台発は安いので決めました。
イタリアに行ってきたばかりなのでお小遣いはほとんど無し。涙。
でも食事付なのでほとんどお金を使う場所が無いと思います。この前の旅行でも昔のようにキラキラした服装でブランドを買いあさってる人は皆無。やっぱり時代は変わったんですよね。けど・・・韓国はお買い物のために行く人がほとんどらしいです。私だけ韓国海苔キムチだけになりそうかも・・・・。
by なっちゃん (2009-12-03 10:22)
韓国まで仙台東京の新幹線代と変わらないということですか。
僕の知ってる釜山で手に入るキムチは日本で買うのとは違いました。辛いけど塩味と大蒜臭が少なくてご飯によく合いました。生協にあるキムチは違う、と思ってしまう。
お土産期待してます。もちろん、お話の、ですが。
by decafish (2009-12-03 22:00)
むふふ。笑。
by なっちゃん (2009-12-08 18:50)
沒有醫生的處方
cialis for daily use http://cialisvipsale.com/ Cialis generic
by Cialis online (2018-04-14 04:02)