アカウント名:
パスワード:
問題のパッチは、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] じゃなかったっけ？
より多くのコメントがこの議論にあるかもしれませんが、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