パスワードを忘れた? アカウント作成
12501466 story
Linux

Linux開発者向けMLに大きなパッチを送るにはどうすれば良い? 56

ストーリー by hylom
ドキュメントを読もう 部門より

昨今では多くの企業やエンジニアがLinuxやその関連プロジェクトに関わっている。Linuxの開発では、コードに加えた変更の差分(いわゆるpatch)をメールでやり取りすることが多いが、日立のエンジニアが「パッチのサイズが大きくなりすぎてメールで送れない」という問題に遭遇したようだ(linux-scsiメーリングリストへの投稿)。

これに対しSUSEのJohannes Thumshirn氏は、「論理的に複数のパッチに分割しろ」との旨の返信をしている。

この問題については「Linux カーネル開発のやり方」ドキュメントの「変更を分割する」や、Linux Foundationによる「Linux カーネル開発への参加方法」の「5.3 パッチの作成」で説明されているが、このようにメールで送れないほどの巨大なパッチを送ることは不適切であり、より粒度が細かい、複数の小さなパッチに分割してそれぞれを個別に送信するのが正解とされている。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 問題のパッチは、56ファイル13万行で4.6MBありますが、
    日立のファイバチャネルボード用のドライバ(hfcldd)を新規追加するもののようです。
    基本的に「複数のパッチに分割」なんてできそうにないと思いますが、いったいどうしろというのでしょうか?…

    対応機種が多いのか、hfcl_detect.c と hfcl_detect_fx.c で3万行取られてるのが大きい感じですので、
    「対応機種の少ないhfclddドライバを新規追加」と「hfclddに対して対応機種を増やすパッチ」という形なら分割できそうですが…無駄に手間をかけるだけだよなぁ。

    • by Anonymous Coward on 2015年09月02日 19時01分 (#2875418)

      対応機種が多いために冗長なソースになっているなら、最初にプロトタイプとして単一機種対応の簡易版を投稿して、-nextあたりにマージしてもらって、対応機種ごとに、機能追加ごとにパッチを追加していくのが本筋かと。
      いきなり社内で開発終わった巨大なパッチをひとまとめに投稿しようというのが、そもそもの誤り。
      そんな巨大なものだイブの人がレビューできるわけないじゃないか。いくら社内で開発終わってて問題ないから入れてくれったって、そんなの通用しないよ。

      親コメント
    • それこそ、githubかどこか借りて、本家をcloneしたあとbranchでっち上げて、そこで必要なソースをぶっこんだ上でmergeしてcommitした上でpull requestをLKMLに投げればいいのに。という感じがしますけどね。
      まぁ、その程度の出費も厳しいのかも知れないですが、そうなると詰んじゃうというか…うーん(;´Д`)

      親コメント
      • 日立社内からはgithubはブロックされてます。

        それに、日立の中の人は、日付ディレクトリとExcelでバージョン管理やっているので、
        gitなんて名前すら知りません。

        親コメント
        • ブロックしてるんですか。まぁ、日立だから仕方ない(´▽`*)アハハという感じではあるのですが(ごめんなさい)。
          それにしても、「それでうまく廻ってるから」そういうヴァージョン管理でやってるんでしょうけど…
          まぁ、件のドライバソースコードを見ると、RCSか何かのヘッダのようなものがあったから、このドライバ等については、あの時代の(古風な)ヴァージョン管理システムは使われてるようですが。

          そうなると、マージされたにしても、その後のサポートも大変なことになりそうですね。いい方法はないものか…

          親コメント
      • by Anonymous Coward

        極普通の形ですな。

        これもダメなら「いいかお前ら、これら10個のパッチはアトミックだから必ず1回でマージしろよ絶対だからな!」宣言してパッチ送ればいいんじゃね?

      • by Anonymous Coward

        しかし、主要なGitサイトは一回100MBまでしか受け付けないそうだ。
        メールで送れないようなパッチを作るやつはすぐに100MBもパンクさせると思われ。

    • 日立製品なのか社員なだけで関係ないファイルなのかで迷ってましたが、
      日立製品ならサポートページにULしたからDLしてね、をMLに回すじゃダメなの?
      親コメント
      • こういうのって、根回しが重要なんです。
        いきなり完成品の巨大パッチ送られても、そんなものレビューできないからお断りといわれるだけだ。

        最初に新しいハード用に新しいドライバを追加したいってお伺いする。
        単一機種用のプロトタイプを投稿してマージしてもらう。
        機能追加と、対応機種追加のパッチを送る。
        もちろん、その間によそ様のパッチが自分のところに影響があるようなら反映する。

        というような、根回ししながら、少しづつ受け入れ要請するのが普通。
        受け入れ時にレビューしてからマージするという過程が発生するということを、よく考えた方がいい。

        たぶん、自社のエンジニアが、大物コミッターとしてコミュニティーに君臨していて、その信頼で、俺が大丈夫と確認したからマージするとかって大ナタ振るわないと無理だよなあ。
        貢献度が大きくて、IntelとかAMD、IBMあたりだと、そういうゴリ押しができるところが強いわけだけれどね。

        親コメント
        • 最初に新しいハード用に新しいドライバを追加したいってお伺いする。
          単一機種用のプロトタイプを投稿してマージしてもらう。
          機能追加と、対応機種追加のパッチを送る。
          もちろん、その間によそ様のパッチが自分のところに影響があるようなら反映する。

          というような、根回ししながら、少しづつ受け入れ要請するのが普通。
          受け入れ時にレビューしてからマージするという過程が発生するということを、よく考えた方がいい。

          原理原則的にはそうでしょうね。
          日立の事情を知らないから推測になりますが、コードを公開するのに稟議を通してやっと承認がとれたから公開したという感じなのでは…07年位からコード書き続けて終わったから公開する。と言う事で、
          今更それに対して、linux-scsi方面に根回しするだけの工数を確保できないとかそういう、ものすごくしょっぱい社内事情がある感じがするんですよね。

          実際、最低限これがあればこの(基本的な)製品が動くはずです。と言う部分だけ抜き出して(それでも1メガバイト近くなる?)パッチで送って、それが承認されたら追加で…と段階を踏んでいくより無いでしょうね。
          git使って送るなら面倒くさいけどブランチを細かくしてやっていく。

          親コメント
        • >いきなり完成品の巨大パッチ送られても、そんなものレビューできないからお断りといわれるだけだ。

          実際そう言われてるね。

          親コメント
        • by Anonymous Coward
          ごめん、自分が理解出来てないみたいなんだけど
          これってカーネルとかディストリに取り入れてくれって話なの?

          パッチって書いてあったから自社製品の独自パッチと考えてたんだけど…。
          • by Anonymous Coward

            以前のsradのタレコミ(このスレッド [linux.srad.jp])でも話題になりました。
            Linuxでは、ある種のドライバはカーネルソースの一部としてでないと実装できない仕様になっているようです。
            そのため、ハードウェアのドライバを実装するだけでも、カーネル開発チームのレビューを受ける必要があります。

            自社製品のドライバを実装するのに、必要もないコードの書き直しが求められるとか、
            コミュニティへの根回しが必要とか、個人的にはちょっと嫌な感じがしますが、
            Linux文化的には当然視されているようですね。

            • > ハードウェアのドライバを実装するだけでも、カーネル開発チームの
              > レビューを受ける必要があります。
              ...
              > Linux文化的には当然視されているようですね。

              OS とハードウェアを製造している会社でハードウェア担当部門が
              ドライバを作ったら OS 部門はドライバのコードレビューをするでしょ。

              当然のことなんであって文化がどうという話ではない。

              親コメント
            • そうなんですか。解説ありがとうございます。
              Linuxは自由なOSではないんですね…。セキュリティ面、堅牢性などの大義名分があるんでしょうが…。

              語弊覚悟でこれでは普及しない訳だ。

              # CentOS7拒否、6で強行
              親コメント
              • 他人があなたのコードを拒否したって、それは相手の自由なんだから当然でしょう?
                あなたにはあなたのコードを使ったり公開する自由があり、また他人から信用ならないコードを
                押し付けられない自由さを持っています。
                なぜ自由なOSでないと思うんでしょう。

                親コメント
              • by Anonymous Coward

                自由の意味を履き違えているとしか……

              • by Anonymous Coward

                普及の要因に自由不自由が関連しているとは思えないな。

              • by Anonymous Coward

                Windowsの場合、Vita以降なら過去のバージョンのドライバがそのまま動いたりするほどバイナリ互換がある。

                Linuxの場合、ドライバやカーネル内部のインタフェースを改良の名のもとに変更しすぎて、カーネルローダブルモジュールに互換性はなく、カーネルとともにメンテし続けないと、簡単に動かないドライバになり果てる。

                RHELとか一部のディストリビュータは、同一世代のディストリビューションの中でカーネルのバイナリー五感を保証して、カーネルローダブルモジュール型のドライバをrpmパッケージ化している。
                バニラのカーネルの場合、いつ内部構造が変更されるかわからないので、カーネルのレポジトリーにドライバを組み込めるかどうかが、死活問題だったりする。レポジトリに組み込まれれば、少なくともインタフェースの非互換が発生するような変更が行われれば、変更しないとコンパイルエラーになるので、変更したい側がメンテナンスせざるを得なくなるわけだ。

              • ドライバすら自由に配布出来ないのは要因になると思いますが。
                メーカーが参入しないのでユーザーは不便で利用しない。
                親コメント
              • by Anonymous Coward

                ドライバ作って配布するのも自分たちでカスタマイズしたカーネルを配布するのも自由ですよ

      • 自己レスだけど、これもしかしてLinuxとかML関係ない?
        単純にでかいファイルがメールに添付できないって事をMLで聞いただけ?
        親コメント
    • Johannesが提言したように「論理的に」分割しましょう。
      逆に、あなたがレビューする立場であると考えてみてください。ひとつのファイルだからといって、13万行のソースを一気読みしますか?
      普通は、まず大まかな流れを掴み、その後に個々のディテールを読み下す、というような流れになると思います。
      つまり、このレビューを助けるような形にソースコードをパッチとして分割するわけです。

      パッチを分割するのは、メールが大きくなりすぎるからというわけではなく、読む「人」が理解しやすいようにする、というのが本来の理由なのです。

      親コメント
    • by Anonymous Coward

      いえいえ、その手間こそ重要。
      scsi_mod.koあたりを変更して関連ドライバを一括修正なんてパッチでも、scsi_mod.koの修正パッチとドライバごとの修正パッチと一連の複数のパッチとして投稿される。
      いくら新規だからって、いきなりそんな巨大なものが送られてきたら、総当たりで一括う修正しなければならないようなパッチに対応漏れが出て対応できないしね。
      そもそも、そんなに巨大なものを、いったい誰が外部でマージするためのレビューができるというのだい?

  • by Anonymous Coward on 2015年09月02日 17時37分 (#2875368)

    リンク先見ると"Maybe you could split it up into a logical patch series." なんだけど
    その訳がそんな目下路線の命令口調になります?
    「Maybe」とか「could」とか重ねてるんでかなり和らげていると思うんですが?

  • by Artane. (1042) on 2015年09月02日 18時11分 (#2875391) 日記

    https://www.kernel.org/doc/Documentation/ja_JP/HOWTO [kernel.org]によると、git pullでのパッチ送付を受け付けてるようなので、とりあえず対外向けのgitをFirewallの外側に立てて、そこにマージを頼みたいコードをpushして、それをpullするようにお願いするとかgithub借りてそこを公開リポジトリにするとかやればいいのに…と思うんですけどね。
    メールでないとパッチ送れないとか、まぁ、大企業ならそういうのもあるのでしょうが…

    3.x カーネルツリー
    -----------------

    3.x カーネルは Linus Torvalds によってメンテナンスされ、kernel.org
    の pub/linux/kernel/v3.x/ ディレクトリに存在します。この開発プロセスは
    以下のとおり-

        - 新しいカーネルがリリースされた直後に、2週間の特別期間が設けられ、
            この期間中に、メンテナ達は Linus に大きな差分を送ることができます。
            このような差分は通常 -next カーネルに数週間含まれてきたパッチです。
            大きな変更は git(カーネルのソース管理ツール、詳細は
            http://git-scm.com/ [git-scm.com] 参照) を使って送るのが好ましいやり方ですが、パッ
            チファイルの形式のまま送るのでも十分です。

  • by Anonymous Coward on 2015年09月02日 19時59分 (#2875455)

    そこまでしてメールを短く簡潔にしたがるんだからパッチのメールも短くして頂きたく。

    • by Anonymous Coward

      難読化ツールにかければよいかね?

      • by Anonymous Coward

        難読化するとGPL違反になる

  • by Anonymous Coward on 2015年09月03日 6時39分 (#2875635)

    どうしてたか。LKML の雰囲気を先例に学ぶ意味でも、これは基礎教養かと。
    http://d.hatena.ne.jp/hyoshiok/20090704/p1 [hatena.ne.jp]
    (今、検索したのでもっと良いまとめとかがあるかも)

    まぁ、個人的には野良モジュールではいかんのか、と思わんでもない

    • by Anonymous Coward

      がちゃぴん先生で検索して、すぐ出てきて欲しいところ

  • by Anonymous Coward on 2015年09月02日 18時00分 (#2875382)

    Linux 4.2-rc1、追加されたコードは100万行以上 [linux.srad.jp]

    AMD の GPU ドライバ関連だけでかなりの行数となっていることが話題になっていますね。
    (このときは全ての変更が 1回のパッチで行われたわけではないと思いますが)

    • by Anonymous Coward

      追加したいのは、これ [hitachi.co.jp]かな
      うーん、こういうのも、パッチとして要求する話なのかな

      • by Anonymous Coward

        タイトルが×パッチ○ドライバって感じですな。

      • by Anonymous Coward

        こっち [hitachi.co.jp]の方が適切か
        BladeSymphonyの方しか見てなかった...

        • 「転載条件:転載不可」になってますね。
          これだと、カーネルメンテナ側では手の出しようがないのでは…
          転載条件をGPLv2にしなければ、ここからダウンロードしてマージするのは無理ですよ。

          親コメント
          • 試しにダウンロードしてみましたが、投稿しようとしているパッチと同一のものですね。
            パッチの方はファイル名と行数の一覧 [marc.info]情報しかありませんが、ファイル名などは一致しました。

            で、このドライバのライセンス条件はGPLになってます。readme.txtによると

            +------------------------------------------------------------------------------+
            +- Hitachi Gigabit Fibre Channel Adapter Driver for Linux                     -+
            +-  Copyright (C) 2004, 2015 Hitachi, Ltd                                     -+
            +------------------------------------------------------------------------------+
             
              本ソフトウェアは、「GNU GENERAL PUBLIC LICENSE」(以下「GPL」といいます。)
            Version 3に従ったオープンソースソフトウェアです。
             
            お客様は、以下の注意事項に同意の上、自己の責任とご判断においてご使用ください。
            (以下略)

            だそうで。

            ていうか、転載禁止が書かれているダウンロードページも、下の方に

            ●お客様へのお願い
            ダウンロードされる前に、下記のご使用条件を必ずお読みのうえ、ご使用条件をご理解ください。 末尾の「同意する」ボタンをクリックしダウンロードされたことをもってご使用条件をご承諾いただき、使用許諾契約が成立したものとさせていただきます。 ご使用条件をご承諾いただけない場合は、「同意しない」ボタンをクリックしページを閉じて下さい。
            本ソフトウェア「GNU GENERAL PUBLIC LICENSE」に対応しております。

            英語版 : http://www.gnu.org/licenses/gpl.html [gnu.org]  (原文)
            日本語版: http://www.opensource.jp/gpl/gpl.ja.html [opensource.jp]  (但し、法的に有効な形ではない)

            ご使用条件は、こちら。

            って書いてあるし…

            親コメント
        • by Anonymous Coward

          実際の利用シーンを考えるに、SIer(笑) が全部面倒をみることになるよね。
          (事務所でパソコンに詳しいお兄さんが任せられちゃうようなシステムに使うかってこと)

          であれば、このままダウンロードしてくださいで放っておいて誰も困らない気がする。
          どうせハード売るときには一緒に日立のエンジニアの人件費も徴収するんだし。

  • 「パッチのサイズが大きくなりすぎてメールで受け取ってくれない」だ。

  • by Anonymous Coward on 2015年09月03日 6時47分 (#2875639)

    なんとかできました。けどでかい…。
    やっぱ(このままでは)無理ですか、無理ですよね
    とりまこれが件の本体です、あげときますね
    まあぼつぼつ、レビューしていただける形で提出しますね

    みたいな

    これが後に、あらたなカーネルプラグインとなる。とかいう夢を一瞬感じた

typodupeerror

皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー

読み込み中...