Linux開発者向けMLに大きなパッチを送るにはどうすれば良い？ 56
ストーリー by hylom
ドキュメントを読もう 部門より
ドキュメントを読もう 部門より
昨今では多くの企業やエンジニアがLinuxやその関連プロジェクトに関わっている。Linuxの開発では、コードに加えた変更の差分（いわゆるpatch）をメールでやり取りすることが多いが、日立のエンジニアが「パッチのサイズが大きくなりすぎてメールで送れない」という問題に遭遇したようだ（linux-scsiメーリングリストへの投稿）。
これに対しSUSEのJohannes Thumshirn氏は、「論理的に複数のパッチに分割しろ」との旨の返信をしている。
この問題については「Linux カーネル開発のやり方」ドキュメントの「変更を分割する」や、Linux Foundationによる「Linux カーネル開発への参加方法」の「5.3 パッチの作成」で説明されているが、このようにメールで送れないほどの巨大なパッチを送ることは不適切であり、より粒度が細かい、複数の小さなパッチに分割してそれぞれを個別に送信するのが正解とされている。
「論理的に複数のパッチに分割」できない時はどうするの? (スコア:3, 参考になる)
問題のパッチは、56ファイル13万行で4.6MBありますが、
日立のファイバチャネルボード用のドライバ(hfcldd)を新規追加するもののようです。
基本的に「複数のパッチに分割」なんてできそうにないと思いますが、いったいどうしろというのでしょうか?…
対応機種が多いのか、hfcl_detect.c と hfcl_detect_fx.c で3万行取られてるのが大きい感じですので、
「対応機種の少ないhfclddドライバを新規追加」と「hfclddに対して対応機種を増やすパッチ」という形なら分割できそうですが…無駄に手間をかけるだけだよなぁ。
Re:「論理的に複数のパッチに分割」できない時はどうするの? (スコア:3, すばらしい洞察)
対応機種が多いために冗長なソースになっているなら、最初にプロトタイプとして単一機種対応の簡易版を投稿して、-nextあたりにマージしてもらって、対応機種ごとに、機能追加ごとにパッチを追加していくのが本筋かと。
いきなり社内で開発終わった巨大なパッチをひとまとめに投稿しようというのが、そもそもの誤り。
そんな巨大なものだイブの人がレビューできるわけないじゃないか。いくら社内で開発終わってて問題ないから入れてくれったって、そんなの通用しないよ。
Re:「論理的に複数のパッチに分割」できない時はどうするの? (スコア:1)
それこそ、githubかどこか借りて、本家をcloneしたあとbranchでっち上げて、そこで必要なソースをぶっこんだ上でmergeしてcommitした上でpull requestをLKMLに投げればいいのに。という感じがしますけどね。
まぁ、その程度の出費も厳しいのかも知れないですが、そうなると詰んじゃうというか…うーん(；´Д｀)
Re:「論理的に複数のパッチに分割」できない時はどうするの? (スコア:1)
日立社内からはgithubはブロックされてます。
それに、日立の中の人は、日付ディレクトリとExcelでバージョン管理やっているので、
gitなんて名前すら知りません。
Re:「論理的に複数のパッチに分割」できない時はどうするの? (スコア:1)
ブロックしてるんですか。まぁ、日立だから仕方ない(´▽｀*)アハハという感じではあるのですが（ごめんなさい）。
それにしても、「それでうまく廻ってるから」そういうヴァージョン管理でやってるんでしょうけど…
まぁ、件のドライバソースコードを見ると、RCSか何かのヘッダのようなものがあったから、このドライバ等については、あの時代の（古風な）ヴァージョン管理システムは使われてるようですが。
そうなると、マージされたにしても、その後のサポートも大変なことになりそうですね。いい方法はないものか…
Re: (スコア:0)
極普通の形ですな。
これもダメなら「いいかお前ら、これら１０個のパッチはアトミックだから必ず１回でマージしろよ絶対だからな！」宣言してパッチ送ればいいんじゃね？
Re: (スコア:0)
しかし、主要なGitサイトは一回100MBまでしか受け付けないそうだ。
メールで送れないようなパッチを作るやつはすぐに100MBもパンクさせると思われ。
Re:「論理的に複数のパッチに分割」できない時はどうするの? (スコア:1)
日立製品ならサポートページにULしたからDLしてね、をMLに回すじゃダメなの？
Re:「論理的に複数のパッチに分割」できない時はどうするの? (スコア:1)
こういうのって、根回しが重要なんです。
いきなり完成品の巨大パッチ送られても、そんなものレビューできないからお断りといわれるだけだ。
最初に新しいハード用に新しいドライバを追加したいってお伺いする。
単一機種用のプロトタイプを投稿してマージしてもらう。
機能追加と、対応機種追加のパッチを送る。
もちろん、その間によそ様のパッチが自分のところに影響があるようなら反映する。
というような、根回ししながら、少しづつ受け入れ要請するのが普通。
受け入れ時にレビューしてからマージするという過程が発生するということを、よく考えた方がいい。
たぶん、自社のエンジニアが、大物コミッターとしてコミュニティーに君臨していて、その信頼で、俺が大丈夫と確認したからマージするとかって大ナタ振るわないと無理だよなあ。
貢献度が大きくて、IntelとかAMD、IBMあたりだと、そういうゴリ押しができるところが強いわけだけれどね。
Re:「論理的に複数のパッチに分割」できない時はどうするの? (スコア:1)
原理原則的にはそうでしょうね。
日立の事情を知らないから推測になりますが、コードを公開するのに稟議を通してやっと承認がとれたから公開したという感じなのでは…０７年位からコード書き続けて終わったから公開する。と言う事で、
今更それに対して、linux-scsi方面に根回しするだけの工数を確保できないとかそういう、ものすごくしょっぱい社内事情がある感じがするんですよね。
実際、最低限これがあればこの（基本的な）製品が動くはずです。と言う部分だけ抜き出して（それでも１メガバイト近くなる？）パッチで送って、それが承認されたら追加で…と段階を踏んでいくより無いでしょうね。
git使って送るなら面倒くさいけどブランチを細かくしてやっていく。
Re:「論理的に複数のパッチに分割」できない時はどうするの? (スコア:1)
＞いきなり完成品の巨大パッチ送られても、そんなものレビューできないからお断りといわれるだけだ。
実際そう言われてるね。
Re: (スコア:0)
これってカーネルとかディストリに取り入れてくれって話なの？
パッチって書いてあったから自社製品の独自パッチと考えてたんだけど…。
Re: (スコア:0)
以前のsradのタレコミ（このスレッド [linux.srad.jp]）でも話題になりました。
Linuxでは、ある種のドライバはカーネルソースの一部としてでないと実装できない仕様になっているようです。
そのため、ハードウェアのドライバを実装するだけでも、カーネル開発チームのレビューを受ける必要があります。
自社製品のドライバを実装するのに、必要もないコードの書き直しが求められるとか、
コミュニティへの根回しが必要とか、個人的にはちょっと嫌な感じがしますが、
Linux文化的には当然視されているようですね。
Re:「論理的に複数のパッチに分割」できない時はどうするの? (スコア:3)
> ハードウェアのドライバを実装するだけでも、カーネル開発チームの
> レビューを受ける必要があります。
...
> Linux文化的には当然視されているようですね。
OS とハードウェアを製造している会社でハードウェア担当部門が
ドライバを作ったら OS 部門はドライバのコードレビューをするでしょ。
当然のことなんであって文化がどうという話ではない。
Re:「論理的に複数のパッチに分割」できない時はどうするの? (スコア:2)
> 他社OSのドライバ出すときに他社のコードレビュー受けるとか当然のことではない。
他社OS用のドライバを他社OSとは全く別に配布する場合と
他社OSの一部としてドライバのコードをマージしてくれと
他社に頼む場合を混同している。
前者の場合なら Linux だってプロプラエタリ・ドライバのコードレビューなんて
していない。
後者ならマージする側の会社は当然、コードレビューするでしょ。
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)
ドライバ作って配布するのも自分たちでカスタマイズしたカーネルを配布するのも自由ですよ
Re:「論理的に複数のパッチに分割」できない時はどうするの? (スコア:1)
単純にでかいファイルがメールに添付できないって事をMLで聞いただけ？
Re:「論理的に複数のパッチに分割」できない時はどうするの? (スコア:1)
Johannesが提言したように「論理的に」分割しましょう。
逆に、あなたがレビューする立場であると考えてみてください。ひとつのファイルだからといって、１３万行のソースを一気読みしますか？
普通は、まず大まかな流れを掴み、その後に個々のディテールを読み下す、というような流れになると思います。
つまり、このレビューを助けるような形にソースコードをパッチとして分割するわけです。
パッチを分割するのは、メールが大きくなりすぎるからというわけではなく、読む「人」が理解しやすいようにする、というのが本来の理由なのです。
Re: (スコア:0)
いえいえ、その手間こそ重要。
scsi_mod.koあたりを変更して関連ドライバを一括修正なんてパッチでも、scsi_mod.koの修正パッチとドライバごとの修正パッチと一連の複数のパッチとして投稿される。
いくら新規だからって、いきなりそんな巨大なものが送られてきたら、総当たりで一括う修正しなければならないようなパッチに対応漏れが出て対応できないしね。
そもそも、そんなに巨大なものを、いったい誰が外部でマージするためのレビューができるというのだい？
「論理的に複数のパッチに分割しろ」との旨の返信 (スコア:2, 参考になる)
リンク先見ると"Maybe you could split it up into a logical patch series." なんだけど
その訳がそんな目下路線の命令口調になります？
「Maybe」とか「could」とか重ねてるんでかなり和らげていると思うんですが？
Re:「論理的に複数のパッチに分割しろ」との旨の返信 (スコア:1)
hylomの英語能力に過大な期待をするな(命令口調)
Re: (スコア:0)
＞hylomの英語能力に過大な期待をするな(命令口調)
め、めいびー。おふこーす。あいのー。
Re: (スコア:0)
あいごー。
Re: (スコア:0)
おぉーいぇー
Re:「論理的に複数のパッチに分割しろ」との旨の返信 (スコア:1)
I go oh 家.
#全日本もう帰りたい協会
Re: (スコア:0)
「との旨」って書いてあんだから、口調について云々することはないだろ
# 他人である身からすればその本心は知る由もないが、自分であれば
# 「くだらねーこと聞くなよ！」って気分の時ほど努めて優しい口調になる
Git使えないのかな (スコア:1)
https://www.kernel.org/doc/Documentation/ja_JP/HOWTO [kernel.org]によると、git pullでのパッチ送付を受け付けてるようなので、とりあえず対外向けのgitをFirewallの外側に立てて、そこにマージを頼みたいコードをpushして、それをpullするようにお願いするとかgithub借りてそこを公開リポジトリにするとかやればいいのに…と思うんですけどね。
メールでないとパッチ送れないとか、まぁ、大企業ならそういうのもあるのでしょうが…
拝承 (スコア:1)
そこまでしてメールを短く簡潔にしたがるんだからパッチのメールも短くして頂きたく。
Re: (スコア:0)
難読化ツールにかければよいかね？
Re: (スコア:0)
難読化するとGPL違反になる
TOMOYO は (スコア:1)
どうしてたか。LKML の雰囲気を先例に学ぶ意味でも、これは基礎教養かと。
http://d.hatena.ne.jp/hyoshiok/20090704/p1 [hatena.ne.jp]
（今、検索したのでもっと良いまとめとかがあるかも）
まぁ、個人的には野良モジュールではいかんのか、と思わんでもない
Re: (スコア:0)
がちゃぴん先生で検索して、すぐ出てきて欲しいところ
関連リンク (スコア:0)
Linux 4.2-rc1、追加されたコードは100万行以上 [linux.srad.jp]
AMD の GPU ドライバ関連だけでかなりの行数となっていることが話題になっていますね。
(このときは全ての変更が 1回のパッチで行われたわけではないと思いますが)
Re: (スコア:0)
追加したいのは、これ [hitachi.co.jp]かな
うーん、こういうのも、パッチとして要求する話なのかな
Re: (スコア:0)
タイトルが×パッチ○ドライバって感じですな。
Re: (スコア:0)
こっち [hitachi.co.jp]の方が適切か
BladeSymphonyの方しか見てなかった...
ライセンスが…（Re:関連リンク (スコア:1)
「転載条件：転載不可」になってますね。
これだと、カーネルメンテナ側では手の出しようがないのでは…
転載条件をGPLv2にしなければ、ここからダウンロードしてマージするのは無理ですよ。
Re:ライセンスが…（Re:関連リンク (スコア:3, 参考になる)
試しにダウンロードしてみましたが、投稿しようとしているパッチと同一のものですね。
パッチの方はファイル名と行数の一覧 [marc.info]情報しかありませんが、ファイル名などは一致しました。
で、このドライバのライセンス条件はGPLになってます。readme.txtによると
だそうで。
ていうか、転載禁止が書かれているダウンロードページも、下の方に
って書いてあるし…
Re: (スコア:0)
Version 3?
Re:ライセンスが…（Re:関連リンク (スコア:1)
v3じゃv2と互換性がないから確かにLinuxカーネルにマージするのは不可能だな。
Re: (スコア:0)
実際の利用シーンを考えるに、SIer(笑) が全部面倒をみることになるよね。
(事務所でパソコンに詳しいお兄さんが任せられちゃうようなシステムに使うかってこと)
であれば、このままダウンロードしてくださいで放っておいて誰も困らない気がする。
どうせハード売るときには一緒に日立のエンジニアの人件費も徴収するんだし。
「パッチのサイズが大きくなりすぎてメールで送れない」ではなく (スコア:0)
「パッチのサイズが大きくなりすぎてメールで受け取ってくれない」だ。
これが1投目 (スコア:0)
なんとかできました。けどでかい…。
やっぱ(このままでは)無理ですか、無理ですよね
とりまこれが件の本体です、あげときますね
まあぼつぼつ、レビューしていただける形で提出しますね
みたいな
これが後に、あらたなカーネルプラグインとなる。とかいう夢を一瞬感じた