/
どうやら、すべての祖は「SCSI」らしい。で、HDDに限っては、「SCSI派」と「IDE派（EIDEもIDEに含めて）」があると。
CDドライブはみんな「SCSI対応機器」じゃぁ。（ホンマかいな…）これをATA規格のコネクタに接続できるのは、「ATAPI」という、「IDEコントローラのレジスタセットを使って、SCSIコマンドを発行するための規格」があるかららしい。（←ハードウェア的視点）（ソフトウェア的視点→）カーネルから見れば、IDEコントローラのドライバでSCSI機器が制御できる、のかな。
（現在においては、「ATA」に「IDE」も「ATAPI」も吸収合併されているから、混乱を極めているのでは無かろうか）
今時ATAPIをサポートしていないATAコントローラなんて無い。そんなわけで結果的に、ATAなコネクタに接続された機器は、ATAコントローラのドライバさえあれば使える。
ただ、分からないのはLinuxに ide-disk ide-cd ide-tape(experimentalらしい) ide-genericというドライバがある点。全部「ATAコマンド」でOKでは無いのかな？ランダムアクセスできるかシーケンシャルしかできないかで、いろいろあるんだろうな…。ide-diskもide-cdも、発行するのは「ATAコマンド」だけど、その発行方法が違うんだろうな。そうなるとide-genericってなんじゃ…
ATAコマンドのide-diskとide-cdに対応するSCSIコマンドのドライバは、sd_modとsr_mod。ふむふむ。で、SCSIコマンドの共通部分を実装したライブラリ的ドライバが、scsi_modと。
「IEEE1394」は、SCSIと似たような接続形態が出来る（←別にそれだけ）、インターフェースの規格。
IEEE1394で使うべきプロトコルというのは、「IEEE1394」で決まっている。DVストリーム（対応するLinuxのドライバはdv1394）とか、IP（eth1394）が流せる。と言うか、当たり前だけど直に叩けば別に何でも流せる（raw1394）
で、その中に「SBP2」（sbp2）というのがある。SCSIコマンドをやりとりするためのプロトコルらしい。SBP2でSCSIコマンドをカプセル化するのかな？これで晴れてIEEE1394のコネクタでSCSI対応機器（すなわちSCSI派のHDDとかCDドライブ全部とか）が全部使えるようになるわけだ。やったねと。
ということで、Linuxでは、コントローラのドライバとsbp2を読み込めばHDDとCDは使える。
ところで、IEEE1394ではIDE派のHDDは使えないのだろうか。
SBP2でHDDが使えるようになるのだから、IEEE1394のケーブルの中ではSCSIコマンドが流れている（…ちょっと違うか…カーネルはSCSIコマンドを発行している）ことになる。
IDE HDDをIEEE1394接続に変換する基盤というのが販売されている。これはどういう仕組みなのか。
変換基盤の中でSCSIコマンドをATAコマンドに変換しているのか…そうなのか、これっぽいな。どうなんだ。（カーネルはSCSI、SCSI<->ATAは変換基盤が行う）
実はIDE派HDDも、今はSCSIコマンドでしゃべっていて、ATAPIが無いと使えないようになっている？…それは無いと思うな…。（カーネルはSCSI、HDDもSCSI）
実はIDE派HDDには「逆ATAPI」が入っていて、ATAコマンドも全部SCSIコマンドとして扱っていて、SCSIコマンドが直で流れてきても問題ない？（カーネルはSCSI、HDDもSCSI（ATAも扱える））
実はIEEE1394のケーブルの中にATAコマンドが流れている？（カーネルはATA、HDDもATA）そうなるとsbp2でIEEE1394接続のIDE派HDDは使えないと言うことになる…そうだとするとドライバは何？
続いてUSB。USBではどんなプロトコルが流されているのかは、よく分からない。
英語版Wikipediaによると、「USB is not intended to be a primary bus for a computer's internal storage: buses such as ATA (IDE) and SCSI fulfill that role.」ということで、USB Storageでも結局のところ、ATAコマンドかSCSIコマンドが流れているらしい。
が、SCSIが流せるというだけで、SCSI派HDDとCDドライブ全部はとりあえず使えるわけです。で、Linuxではそのドライバはusb-storage。
IEEE1394のsbp2と同じようなものなんだろうな。
最近策定された規格では、「コントローラの標準規格」が存在する模様。ATAコントローラやSCSIコントローラでは各ベンダーの仕様が乱立していて、それぞれに適したドライバを読み込まないといけない。
実際USB 2.0では、ehci-hcdを読み込むだけでほとんどのチップが制御できるらしい。
USB 1.1にはUHCIとOHCIの2つがあるけど。
IEEE1394にはUHCIというのがある。USBのUHCIとの関係は不明。Serial ATAにはACHI。
で、どうもこれらはいわゆるデファクトスタンダードという類のもので、だいたいIntelが提唱したものであるところ、Intelの大企業さが分かる。
カーネルの側からすれば、当然統一された方がうれしい。VIVERもうれしい。USBならEHCI、Serial ATAならAHCI。それで終わり。スバラシイ。
PCIの自動検出で結局重要なのは、クラスの判別（USBホストコントローラなのか、USBなのか、Serial ATAなのか）かな、という結論でした。
NICにもこんな調子で標準規格があると良いんだけどな。デファクトスタンダードを確立できるほど淘汰が進んでいないのかな。NICも歴史の古いデバイスだし。（なんて10代が言うのも変な気がするなぁ…）
NICにもNE2000という最大公約数的なデファクトスタンダードがあるらしいけど、これだと性能が出ないんだろうな。
ストレージは結局DMAだったりして、チップの多様性が少ないのかな。だからデファクトスタンダードが登場すると。そうなるとNICとか、ましてGPUなんて無理だろうな…。
AMDがATIを買収と言うことで、数値演算コプロセッサがCPUに統合されたように、GPUがCPUに統合されるようになるとすれば、「x86」とか「Power PC」とかと同列のところにたとえば「AMD CISCアーキテクチャ」なんて出てきて、GPUの分も含めた「AMD CISC命令セット」が定められるとか。そうなるとアーキテクチャなんてコロコロ変えていられないから、自ずとGPUのドライバにデファクトスタンダードが発生。「この仮想化ソフトウェアはAMD CISCしか対応していません」とか、そんなことになってきて、逆に「AMD CISC」に対応しているなら、統合されているGPU分の命令セットにも対応できるわけで、そうなるとVMからGPUを直で叩けることになる、みたいな。むーだからどうなのかは知らない…PlayStation3でもVMからGPUを直で叩いているんだろうしな。
そうなると、VIVERはHypervisor的層で動かすのがうれしい、ってなって、Xenのソースコードを解析開始〜とか、そんなですか。
ぁ、もう、良くワカラン。
まぁいいや。
