[pbsd-mg2] Platform ID

[UCHIYAMA Yasushi <uch@nop.or.jp>]

 | どちらも半分 YES です。
 | 最終的（理想的）には、ほとんどの場合はデバイスの有／無、デバイスの
 | アドレス（location）で切り分けられるので、そういう意味では YES です。
 | しかし、そういうきっちりいかない部分、ソースファイル内で
 | #ifdef XXX_MCR510_WORKAROUND ... #endif なんていうものがあって、
 | configration file にも option XXX_MCR510_WORKAROUND などと書くならば、
 | 結局Platform ID の値を #define のようなもので静的に
 | カーネルに埋め込むのと同じことになると思います。

 | さしあたって問題なのは vrgiu の先です。
 | GIU には 1 bit のデータポートがいくつかあります。
 | あるビットはある機種では RS232C の PHY の電源の ON/OFF が割り当てられて
 | います。このビットは違う機種ではブザーや場合によってはシステムリセット
 | などに割り当てられているかも知れません。
 | 1bit しかないので、直接的な probe ほぼ不可能です。

#ifdef `プラットフォーム`あるいはplatid_matchを、vr*.cに入れるのでなく、
vr*.cは、vr41x1に依存するものだけ、個々のマシンに依存にするものは、
vr/platform/nec_mcr510.cとかに分離するようにして、vr*.cからは例えば
vr_product_t->poweron()で呼ぶようにする方が見通しも、メンテナンス性も
高いように思うんですが...
# alphaのstruct alpha_pci_chipsetみたいな感じで。
これも根本的に難しい...ですか?

 | PC Card や PCI card のように probe できるように設計されたデバイスを
 | probe するのは賛成ですが、それ以外のほとんどのデバイスを試行錯誤して
 | probe するよりも platform ID のようなもので統一的に扱えた方が
 | いいのかも、と思って作ってみました。

 PC CardやPCIは、バスデバイス自身が、子デバイスを知ることのできる
direct configurationのバス(config_foundを使う)なので、別かと。
 indirect configuration(ISAのような)バスであれば、一般的には子デバイス
の存在自体わかりません。ただ、hpcmipsのターゲットの場合platformから先
験的に全てがわかるので、platformで区別するという方法もありというところ
でしょうか。

#もうちょっと見てみます。
---
UCHIYAMA Yasushi
uch@nop.or.jp