アカウント名:
パスワード:
問題のパッチは、56ファイル13万行で4.6MBありますが、日立のファイバチャネルボード用のドライバ(hfcldd)を新規追加するもののようです。基本的に「複数のパッチに分割」なんてできそうにないと思いますが、いったいどうしろというのでしょうか?…
対応機種が多いのか、hfcl_detect.c と hfcl_detect_fx.c で3万行取られてるのが大きい感じですので、「対応機種の少ないhfclddドライバを新規追加」と「hfclddに対して対応機種を増やすパッチ」という形なら分割できそうですが…無駄に手間をかけるだけだよなぁ。
こういうのって、根回しが重要なんです。いきなり完成品の巨大パッチ送られても、そんなものレビューできないからお断りといわれるだけだ。
最初に新しいハード用に新しいドライバを追加したいってお伺いする。単一機種用のプロトタイプを投稿してマージしてもらう。機能追加と、対応機種追加のパッチを送る。もちろん、その間によそ様のパッチが自分のところに影響があるようなら反映する。
というような、根回ししながら、少しづつ受け入れ要請するのが普通。受け入れ時にレビューしてからマージするという過程が発生するということを、よく考えた方がいい。
たぶん、自社のエンジニアが、大物コミッターとしてコミュニティーに君臨していて、その信頼で、俺が大丈夫と確認したからマージするとかって大ナタ振るわないと無理だよなあ。貢献度が大きくて、IntelとかAMD、IBMあたりだと、そういうゴリ押しができるところが強いわけだけれどね。
以前のsradのタレコミ（このスレッド [linux.srad.jp]）でも話題になりました。Linuxでは、ある種のドライバはカーネルソースの一部としてでないと実装できない仕様になっているようです。そのため、ハードウェアのドライバを実装するだけでも、カーネル開発チームのレビューを受ける必要があります。
自社製品のドライバを実装するのに、必要もないコードの書き直しが求められるとか、コミュニティへの根回しが必要とか、個人的にはちょっと嫌な感じがしますが、Linux文化的には当然視されているようですね。
> ハードウェアのドライバを実装するだけでも、カーネル開発チームの> レビューを受ける必要があります。...> Linux文化的には当然視されているようですね。
OS とハードウェアを製造している会社でハードウェア担当部門がドライバを作ったら OS 部門はドライバのコードレビューをするでしょ。
当然のことなんであって文化がどうという話ではない。
自社内ならそうでしょう。当然日立もしてると思いますよ。しかし、他社OSのドライバ出すときに他社のコードレビュー受けるとか当然のことではない。Windows用のドライバはMSがレビューするのが当然とかありえないことは分かるでしょうに。最近はドライバに限らずカーネル機能の多くをモジュール化して、さらに動的な付け外しすら可能にするのが流れなんだが……
そのかわりじゃないけどWHQLテストがあるし、Linuxもモジュール化することと、一体のソースセット内に入ることでのレビューは別の問題でしょう。
# あとLinuxでのモジュールは、マージできるオープンソースであること、マージして変化に追従するって流れもあるので、なんか提示している問題がちがう気がするぞ
> 他社OSのドライバ出すときに他社のコードレビュー受けるとか当然のことではない。
他社OS用のドライバを他社OSとは全く別に配布する場合と他社OSの一部としてドライバのコードをマージしてくれと他社に頼む場合を混同している。
前者の場合なら Linux だってプロプラエタリ・ドライバのコードレビューなんてしていない。
後者ならマージする側の会社は当然、コードレビューするでしょ。
「ある種のドライバはカーネルソースの一部としてでないと実装できない仕様」これが諸悪の根源ですね。「他社OS用のドライバを他社OSとは全く別に配布する」という手段が取れない。
その制限を克服するための仕掛けが DKMS [wikipedia.org] じゃなかったっけ？
他人があなたのコードを拒否したって、それは相手の自由なんだから当然でしょう？あなたにはあなたのコードを使ったり公開する自由があり、また他人から信用ならないコードを押し付けられない自由さを持っています。なぜ自由なOSでないと思うんでしょう。
自由の意味を履き違えているとしか……
普及の要因に自由不自由が関連しているとは思えないな。
Windowsの場合、Vita以降なら過去のバージョンのドライバがそのまま動いたりするほどバイナリ互換がある。
Linuxの場合、ドライバやカーネル内部のインタフェースを改良の名のもとに変更しすぎて、カーネルローダブルモジュールに互換性はなく、カーネルとともにメンテし続けないと、簡単に動かないドライバになり果てる。
RHELとか一部のディストリビュータは、同一世代のディストリビューションの中でカーネルのバイナリー五感を保証して、カーネルローダブルモジュール型のドライバをrpmパッケージ化している。バニラのカーネルの場合、いつ内部構造が変更されるかわからないので、カーネルのレポジトリーにドライバを組み込めるかどうかが、死活問題だったりする。レポジトリに組み込まれれば、少なくともインタフェースの非互換が発生するような変更が行われれば、変更しないとコンパイルエラーになるので、変更したい側がメンテナンスせざるを得なくなるわけだ。
ドライバ作って配布するのも自分たちでカスタマイズしたカーネルを配布するのも自由ですよ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
「論理的に複数のパッチに分割」できない時はどうするの? (スコア:3, 参考になる)
問題のパッチは、56ファイル13万行で4.6MBありますが、
日立のファイバチャネルボード用のドライバ(hfcldd)を新規追加するもののようです。
基本的に「複数のパッチに分割」なんてできそうにないと思いますが、いったいどうしろというのでしょうか?…
対応機種が多いのか、hfcl_detect.c と hfcl_detect_fx.c で3万行取られてるのが大きい感じですので、
「対応機種の少ないhfclddドライバを新規追加」と「hfclddに対して対応機種を増やすパッチ」という形なら分割できそうですが…無駄に手間をかけるだけだよなぁ。
Re: (スコア:1)
日立製品ならサポートページにULしたからDLしてね、をMLに回すじゃダメなの？
Re: (スコア:1)
こういうのって、根回しが重要なんです。
いきなり完成品の巨大パッチ送られても、そんなものレビューできないからお断りといわれるだけだ。
最初に新しいハード用に新しいドライバを追加したいってお伺いする。
単一機種用のプロトタイプを投稿してマージしてもらう。
機能追加と、対応機種追加のパッチを送る。
もちろん、その間によそ様のパッチが自分のところに影響があるようなら反映する。
というような、根回ししながら、少しづつ受け入れ要請するのが普通。
受け入れ時にレビューしてからマージするという過程が発生するということを、よく考えた方がいい。
たぶん、自社のエンジニアが、大物コミッターとしてコミュニティーに君臨していて、その信頼で、俺が大丈夫と確認したからマージするとかって大ナタ振るわないと無理だよなあ。
貢献度が大きくて、IntelとかAMD、IBMあたりだと、そういうゴリ押しができるところが強いわけだけれどね。
Re:「論理的に複数のパッチに分割」できない時はどうするの? (スコア:0)
これってカーネルとかディストリに取り入れてくれって話なの？
パッチって書いてあったから自社製品の独自パッチと考えてたんだけど…。
Re: (スコア:0)
以前のsradのタレコミ（このスレッド [linux.srad.jp]）でも話題になりました。
Linuxでは、ある種のドライバはカーネルソースの一部としてでないと実装できない仕様になっているようです。
そのため、ハードウェアのドライバを実装するだけでも、カーネル開発チームのレビューを受ける必要があります。
自社製品のドライバを実装するのに、必要もないコードの書き直しが求められるとか、
コミュニティへの根回しが必要とか、個人的にはちょっと嫌な感じがしますが、
Linux文化的には当然視されているようですね。
Re:「論理的に複数のパッチに分割」できない時はどうするの? (スコア:3)
> ハードウェアのドライバを実装するだけでも、カーネル開発チームの
> レビューを受ける必要があります。
...
> Linux文化的には当然視されているようですね。
OS とハードウェアを製造している会社でハードウェア担当部門が
ドライバを作ったら OS 部門はドライバのコードレビューをするでしょ。
当然のことなんであって文化がどうという話ではない。
Re: (スコア:0)
自社内ならそうでしょう。
当然日立もしてると思いますよ。
しかし、他社OSのドライバ出すときに他社のコードレビュー受けるとか当然のことではない。
Windows用のドライバはMSがレビューするのが当然とかありえないことは分かるでしょうに。
最近はドライバに限らずカーネル機能の多くをモジュール化して、さらに動的な付け外しすら可能にするのが流れなんだが……
Re: (スコア:0)
そのかわりじゃないけどWHQLテストがあるし、Linuxもモジュール化することと、一体のソースセット内に入ることでのレビューは別の問題でしょう。
# あとLinuxでのモジュールは、マージできるオープンソースであること、マージして変化に追従するって流れもあるので、なんか提示している問題がちがう気がするぞ
Re:「論理的に複数のパッチに分割」できない時はどうするの? (スコア:2)
> 他社OSのドライバ出すときに他社のコードレビュー受けるとか当然のことではない。
他社OS用のドライバを他社OSとは全く別に配布する場合と
他社OSの一部としてドライバのコードをマージしてくれと
他社に頼む場合を混同している。
前者の場合なら Linux だってプロプラエタリ・ドライバのコードレビューなんて
していない。
後者ならマージする側の会社は当然、コードレビューするでしょ。
Re: (スコア:0)
「ある種のドライバはカーネルソースの一部としてでないと実装できない仕様」
これが諸悪の根源ですね。
「他社OS用のドライバを他社OSとは全く別に配布する」という手段が取れない。
Re:「論理的に複数のパッチに分割」できない時はどうするの? (スコア:2)
その制限を克服するための仕掛けが DKMS [wikipedia.org] じゃなかったっけ？
uxi
Re:「論理的に複数のパッチに分割」できない時はどうするの? (スコア:1)
Linuxは自由なOSではないんですね…。セキュリティ面、堅牢性などの大義名分があるんでしょうが…。
語弊覚悟でこれでは普及しない訳だ。
# CentOS7拒否、6で強行
Re:「論理的に複数のパッチに分割」できない時はどうするの? (スコア:1)
他人があなたのコードを拒否したって、それは相手の自由なんだから当然でしょう？
あなたにはあなたのコードを使ったり公開する自由があり、また他人から信用ならないコードを
押し付けられない自由さを持っています。
なぜ自由なOSでないと思うんでしょう。
Re: (スコア:0)
自由の意味を履き違えているとしか……
Re: (スコア:0)
普及の要因に自由不自由が関連しているとは思えないな。
Re: (スコア:0)
Windowsの場合、Vita以降なら過去のバージョンのドライバがそのまま動いたりするほどバイナリ互換がある。
Linuxの場合、ドライバやカーネル内部のインタフェースを改良の名のもとに変更しすぎて、カーネルローダブルモジュールに互換性はなく、カーネルとともにメンテし続けないと、簡単に動かないドライバになり果てる。
RHELとか一部のディストリビュータは、同一世代のディストリビューションの中でカーネルのバイナリー五感を保証して、カーネルローダブルモジュール型のドライバをrpmパッケージ化している。
バニラのカーネルの場合、いつ内部構造が変更されるかわからないので、カーネルのレポジトリーにドライバを組み込めるかどうかが、死活問題だったりする。レポジトリに組み込まれれば、少なくともインタフェースの非互換が発生するような変更が行われれば、変更しないとコンパイルエラーになるので、変更したい側がメンテナンスせざるを得なくなるわけだ。
Re:「論理的に複数のパッチに分割」できない時はどうするの? (スコア:1)
メーカーが参入しないのでユーザーは不便で利用しない。
Re: (スコア:0)
ドライバ作って配布するのも自分たちでカスタマイズしたカーネルを配布するのも自由ですよ