アカウント名:
パスワード:
問題のパッチは、56ファイル13万行で4.6MBありますが、日立のファイバチャネルボード用のドライバ(hfcldd)を新規追加するもののようです。基本的に「複数のパッチに分割」なんてできそうにないと思いますが、いったいどうしろというのでしょうか?…
対応機種が多いのか、hfcl_detect.c と hfcl_detect_fx.c で3万行取られてるのが大きい感じですので、「対応機種の少ないhfclddドライバを新規追加」と「hfclddに対して対応機種を増やすパッチ」という形なら分割できそうですが…無駄に手間をかけるだけだよなぁ。
こういうのって、根回しが重要なんです。いきなり完成品の巨大パッチ送られても、そんなものレビューできないからお断りといわれるだけだ。
最初に新しいハード用に新しいドライバを追加したいってお伺いする。単一機種用のプロトタイプを投稿してマージしてもらう。機能追加と、対応機種追加のパッチを送る。もちろん、その間によそ様のパッチが自分のところに影響があるようなら反映する。
というような、根回ししながら、少しづつ受け入れ要請するのが普通。受け入れ時にレビューしてからマージするという過程が発生するということを、よく考えた方がいい。
たぶん、自社のエンジニアが、大物コミッターとしてコミュニティーに君臨していて、その信頼で、俺が大丈夫と確認したからマージするとかって大ナタ振るわないと無理だよなあ。貢献度が大きくて、IntelとかAMD、IBMあたりだと、そういうゴリ押しができるところが強いわけだけれどね。
以前のsradのタレコミ（このスレッド [linux.srad.jp]）でも話題になりました。Linuxでは、ある種のドライバはカーネルソースの一部としてでないと実装できない仕様になっているようです。そのため、ハードウェアのドライバを実装するだけでも、カーネル開発チームのレビューを受ける必要があります。
自社製品のドライバを実装するのに、必要もないコードの書き直しが求められるとか、コミュニティへの根回しが必要とか、個人的にはちょっと嫌な感じがしますが、Linux文化的には当然視されているようですね。
Windowsの場合、Vita以降なら過去のバージョンのドライバがそのまま動いたりするほどバイナリ互換がある。
Linuxの場合、ドライバやカーネル内部のインタフェースを改良の名のもとに変更しすぎて、カーネルローダブルモジュールに互換性はなく、カーネルとともにメンテし続けないと、簡単に動かないドライバになり果てる。
RHELとか一部のディストリビュータは、同一世代のディストリビューションの中でカーネルのバイナリー五感を保証して、カーネルローダブルモジュール型のドライバをrpmパッケージ化している。バニラのカーネルの場合、いつ内部構造が変更されるかわからないので、カーネルのレポジトリーにドライバを組み込めるかどうかが、死活問題だったりする。レポジトリに組み込まれれば、少なくともインタフェースの非互換が発生するような変更が行われれば、変更しないとコンパイルエラーになるので、変更したい側がメンテナンスせざるを得なくなるわけだ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
「論理的に複数のパッチに分割」できない時はどうするの? (スコア: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: (スコア:1)
Linuxは自由なOSではないんですね…。セキュリティ面、堅牢性などの大義名分があるんでしょうが…。
語弊覚悟でこれでは普及しない訳だ。
# CentOS7拒否、6で強行
Re:「論理的に複数のパッチに分割」できない時はどうするの? (スコア:0)
Windowsの場合、Vita以降なら過去のバージョンのドライバがそのまま動いたりするほどバイナリ互換がある。
Linuxの場合、ドライバやカーネル内部のインタフェースを改良の名のもとに変更しすぎて、カーネルローダブルモジュールに互換性はなく、カーネルとともにメンテし続けないと、簡単に動かないドライバになり果てる。
RHELとか一部のディストリビュータは、同一世代のディストリビューションの中でカーネルのバイナリー五感を保証して、カーネルローダブルモジュール型のドライバをrpmパッケージ化している。
バニラのカーネルの場合、いつ内部構造が変更されるかわからないので、カーネルのレポジトリーにドライバを組み込めるかどうかが、死活問題だったりする。レポジトリに組み込まれれば、少なくともインタフェースの非互換が発生するような変更が行われれば、変更しないとコンパイルエラーになるので、変更したい側がメンテナンスせざるを得なくなるわけだ。