アカウント名:
パスワード:
さらにハードウェアバグの回避の為に, 仕様書と異なるコードが書かれているなんてことも当然起こりうるわけで.
Miller氏は、UltraSPARC III版Linuxを見れば、同プロセッサの仕組みは「はっきりと分かる」と考えている。だがde Raadt氏によると、OpenBSDプログラマーたちがその方法を試してみたが、役に立たなかったという。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
よくわからないのですが (スコア:1)
Re:よくわからないのですが (スコア:4, 興味深い)
GPLでソースコードは公開しないといけないけど、詳細に仕様をコメントに書く必要はなし。
それでも、無いよりはずっとマシってのが今回の考え方で、現実的ではあるけど、周りの迷惑考えろって言ってる人たちのこともわからないではない。
コードだけGPLでも (スコア:2, 興味深い)
それが本当に仕様どおりに作成されているかの検証すら第3者には不可能。
と思えるのですが違うのでしょうか?
Re:コードだけGPLでも (スコア:1)
さらにハードウェアバグの回避の為に, 仕様書と異なるコードが書かれているなんてことも当然起こりうるわけで.
仕様の範囲 (スコア:2, 興味深い)
仕様書をどこまで書くかはいろいろなんだろうけど、普通の状況では使わない仕様というのもあるんじゃ
ないかな。たとえば、最近まで関係していたTV用デバイスだと、いろいろな形式の入力画像信号を統一的
な形式で出力するというものがある。が、普通はFPlinkというLVDSしか使わない。赤外線リモコン入力信
号も普通は1chしかとれないけど、実際は最大100個とれる。シリアルコンソールが実は2個繋がると
いのも初期の仕様にはあった。最終的にはその部分は検証が間に合わず、仕様書にはあっても使えるかど
うかは不明ということになった。
けど、もしセットになったら絶対にそんな機能は使わない&使えない。従ってDriverソフトをどんなに
見たってそんな機能があることは分からない。シリアルコンソールも普通にRS232Cとかに繋げたければ電
圧を上げないといけないので、仕様書無しでは、適当に総当りで試しても簡単に探し出せるものではない。
というわけで、仕様書の中でdriver開発に使われるのはほんの一部なんではないかな?DVD用のdevice
でもregion codeを無視するとか、region codeの変更回数とかも含めて「出荷時の状態に戻す」なんての
も仕様書には書いてあったりして。
まずい部分を隠して仕様書を書き直すというのもアリだけど、開発が終了したデバイスに対してそんな
面倒なことはしたくない。「この製品版のグラフィックカードを改造なしで使える範囲だけしかドライバ
として実装しない。」という文面にサインさせれば多少の逸脱があっても、見逃すといのがコスト的には
見合うのでは?
Re:よくわからないのですが (スコア:1, 参考になる)
Linuxのドライバで使えた方法がOpenBSDでそのまま使えないって話は以前もあった。
あのときもLinux陣営はさっさとNDAを結んで、Theoは情報を開示しろって吠えたけどもう忘れた?
OpenBSD開発者、Sunのオープンソース対応を批判 [archive.org]
ドライバのソースを公開することで、全てを公開したことと同義になるなら
EUの命令に対して、Windowsのソース公開で対応しようとしたマイクロソフトはどうなるの。
あれ結局、仕様書がないと駄目だって突っぱねられたんでしょう。
そこの所をよく考えてね。