SMART on Solaris/x86

/var/crash日記: OpenSolarisのバグデータベースとSMARTの続き。

ata_common.cとata_disk.cをつらつら眺めてみて、こんなシナリオはどうだろうというのを考え付いた。

1. ユーザから渡されたcmdとargはdadk_ioctl()内でもそのまま保持されてる。もしcmdに入っているコマンドがdadk_ioctl()に理解できず、かつデバイスがリムーバブルメディアでないとすると、cmdとargを引数としてata_disk_ioctl()が呼ばれる。
   
2. ata_disk_ioctl()ではPIOデータ転送パケットpioを確保してやり、ata_queue_cmd(ata_pio_in, pio, ata_ctlp, ata_drvp, gtgtp)を呼び出してやる。
   
3. するとata_ctlp->ap_v_dataにpioのアドレスが入ってからata_pio_in(ata_ctlp, ata_drvp, ata_pktp)が呼ばれる。
   
4. ata_pio_in()ではata_id_commin()似のPIOデータ転送を行なう(ata_id_common()だとCOMMANDレジスタ以外のレジスタが設定できないし、ata_command()はnon-data用の関数なのでデータ転送を行なう前にSTATUSレジスタを読んでしまう)。ata_pio_in()にはata_ctlpが渡せるので、そこからpio、すなわちSMARTデータ用のバッファのアドレスを得ることができる。作業が終わったら、ATA_FSM_RC_FINIを返してFSMに状態遷移を起こさせる。
   

完璧? 話のつじつまはあいそう。ただ、ata_command()もata_id_common()もata_disk_*_pio_in()すらも使わないのはちょっとｶｺﾜﾙｲ。
それに仮にこのやり方がうまく逝ったとしても、ataドライバはかなり変更が大きいところなので、Solaris/x86のものをOpenSolarisベースのものに置き換えて大丈夫かはかなりギャンブルだと思う。外部インターフェースがそうそう変化しないことを祈るか、でなければobjmgrを使いこなすかか。
あと、OpenSolarisのコンパイル方法を調べておかないと…