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

Linux 4.2-rc1、追加されたコードは100万行以上 35

ストーリー by hylom
ハードウェアサポートの大変さが分かるお話 部門より
headless 曰く、

Linux 4.2-rc(リリース候補版)1が7月5日にリリースされた。変更された行数で見ると過去最大のrcになるという(メーリングリストでのアナウンスV3.co.ukThe RegisterPhoronix)。

Linus Torvalds氏によれば、4.2-rc1では100万行以上のコードが追加されおよそ25万行が削除されたという。およそ49%がAMDの新しいGPUドライバ関連のものとなっており、単一のドライバがパッチ全体の半分近くを占めるという、少し変わった状況になっているそうだ。一方、その他の変更点はいたって普通で、主にドライバーやアーキテクチャーの更新のほか、ファイルシステム関連の変更などが含まれる。ただしアーキテクチャー関連では、安定していてあまり変更されることのないローレベルのx86コードの一部で整理が行われた点が通常とは異なるとのこと。

なお、4.1-rc1はコミット数でみても過去最大級といえるが、3.15-rc1よりもわずかに少ないという。また、3.10-rc1のコミット数は4.2-rc1と同じぐらいであり、ファイナルリリース版ではさらに増加している。ただし、rc-1以降では多くのコミットをマージしない方向に進んでいるため、4.2が3.10と比較するほど大きなリリースになるとは考えていないようだ。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2015年07月10日 7時42分 (#2845213)

    掃除のおばちゃんが100万のコードを

    • by Anonymous Coward

      ところで、IT業界では、掃除のおばちゃんって、部屋の中まで入ってくるんですか?

      • by Anonymous Coward on 2015年07月10日 8時57分 (#2845241)

        IT業界に限らず清掃を外部委託してれば当然ながら入ってきます

        アメリカでは掃除は掃除人がやるもので社員がやるものではないみたいですね

        親コメント
  • by Anonymous Coward on 2015年07月10日 9時51分 (#2845268)

    よくわかってないんだけど、たかが1ベンダのドライバがカーネルの一部としてリリースされるの?
    とすると、Linuxのカーネルには主要なGPUに対するドライバが全部含まれてて、
    新しいベンダからGPU製品がリリースされたら、カーネルを変更しないと使えないの?

    よくいうLinuxはmonolithic構造だから、っていう話かな。

    • 既に、述べられてる点 [linux.srad.jp]を除いて細かいところを書いておきますね。

      基本的には、x86系で主に使われるGPUメーカで、IntelとAMDは積極的にオープンソースに対して協力的ですし、ARM SoCの幾つかのメーカも協力的ですが、nVidiaは余り協力的ではないということがあります。

      AMDは最近GPU関連に力を入れていて、例えば「次世代OpenGL」のクロスプラットフォームAPIとして規格化されたVulkan [impress.co.jp]の基になったMantle [4gamer.net]を開発・実装していたり、GPUで色々計算をやらせるための規格であるOpenCL [wikipedia.org]に力を入れています。

      で、最近、AMDがGPU周りの資源共有に対して、他の会社に先行して大きな変更を入れていて、AMDKFD [phoronix.com]と言うドライバを投入してきました。
      これはいつも使われてるOpenGLやGLの一機能で大きな役割を担ってるGLSL、更にはOpenCLやVulkanを滞りなく並行して使えるようにする目的の物で、今のところ対応してるのは主に新しいAPUやGPUに限られているようですが、最終的には全ての(AMD製)GPUでこれを噛ませるようにしていこうとしてるっぽいです。

      こんな事があって、最近のAMD製のGPUに関するドライバは相当な勢いで毎回変更されてマージされてる状況です。これがある程度落ち着いて機能の有効性が確立したら、今度はIntelやARM SoCに統合されてるGPUでの対応作業が追随していくのではないかと思います。nVidiaはわからないですが(^_^;

      親コメント
      • by Anonymous Coward

        SteamOSでValveと協力してOpenGLにも力入れるぜ!って宣言 [nvidia.com]はしてましたけどね。

        • ああ、言葉が足りなかったけど、オープンソースドライバの話です。
          nVidiaの場合は、お世辞にもオープンソースドライバのサポートがいいとは言い難くて、AMDやIntelと較べて対応がかなり遅れてます [freedesktop.org]。
          と言うのも、オープンソースのnVidia GPU向けドライバというのは、元々はクローズドソースなドライバしか出してこないのに憤慨した人がリバースエンジニアリングを重ねてリリースしていたという経緯も関係してるのか、nVidiaの技術的サポート自体が歴史的に手薄で、Linusが公の場で強い不快感を示して [gihyo.jp]やっと、メーカ側のサポートが本格的に入った?と言う感じなんですよ。
          他社と較べて数年は遅れてる。

          nVidiaだけではなく、AMDもクローズドソースなドライバを出してますが、これはOpenGL4.2やOpenCL2.0のような、最先端の技術や規格をサポートしてる代わりに安定しない場合が多いという物で、ここで安定した技術(の一部)をオープンソースに持ち込んでるような感じなんですよね。
          nVidiaの場合は、安定性と性能、両方共クローズドソースでないと満足できない状態がまだまだ続いてる感じがしますけどね。

          だから、ここで「OpenGLにも力を入れる」というのは、あくまでクローズドソースのドライバの充実に関する話だと思いますよ。

          親コメント
    • by Anonymous Coward on 2015年07月10日 10時36分 (#2845289)

      昔はGPU関係の処理はユーザーランドで動作するXserverに切り離されてたんですが、
      カーネル内の Direct Renering Manager http://dri.freedesktop.org/wiki/DRM/ [freedesktop.org] で
      提供されるように変わってきました。(理由もこのページに書いてあります)

      従来のようにユーザーランドにドライバを置くこともできるにはできるんですが、
      最新のGPUは、あらかた DRM を使うようになってます。

      とは言うものの、タレコミにあるように単一のドライバで50万行というのが本当ならば、
      そんなものをカーネル空間で動かすのは危険としかいいようがない気がします。
      現行の DRM の仕様は、カーネル側で担当する仕事が多すぎるんじゃないかなあ。
      ある程度はカーネル側でやった方がいいにしても、せいぜい数万行オーダーで済む範囲内に
      しておいて、残りの仕事はXserverに戻したほうが良い気がします。

      親コメント
      • by Anonymous Coward on 2015年07月10日 11時01分 (#2845299)

        元コメの疑問への回答としては、引用されているページのここですかね。

        Since internal Linux kernel interfaces and data structures may be changed at any time, DRI kernel modules must be specially compiled for a particular kernel version.
        (Linuxカーネルの内部インターフェイスとデータ構造は随時変更されるため、DRIカーネルモジュールは特定のカーネルバージョン専用にコンパイルされなければならない。)

        monolithicとかいう高尚な次元の話じゃなかった。

        親コメント
        • by Anonymous Coward
          ドライバ作る側も大変そうだな。
          • by Anonymous Coward

            これのおかげでLinuxデスクトップではドライバのインストール問題が極めて少ない
            カーネルに全部入ってるか、なくてもディストロが一緒にコンパイルして配ってくれる

            • by Anonymous Coward

              はあ?じゃ、俺がGPUハードウェアを開発したとして、それを使いたい顧客はどうやってドライバを手持ちのマシンにインストールすんの?

              俺が独自ディストロ作って配るか、Linuxカーネルのメインラインにマージしてもらわないといけないわけ?

              • by Anonymous Coward

                VMware Toolsだとこんな具合。

                ・メジャーディストロ向けにはコンパイル済みのドライバモジュールが用意されていて、それがインストールされる
                ・上記に該当しない場合はドライバモジュールをソースからコンパイルしてインストール(要カーネルソース)

                では頑張ってGPU開発してくれ :-P

              • by Anonymous Coward

                はいけーもっど〜(D0R@EM0N風に)
                まあカーネルのアップデートで画面が映らなくなったりしますが個人でGPUを作っちゃったりする暇人なら恐らく問題ないでしょう。

              • by Anonymous Coward

                うーん、素人考えだとコンパイル済みのドライバモジュールとやらを各ベンダーがカーネルバージョン毎に用意すればいいだけに思えるのですが、何で本家Linuxカーネル側がソースに取り込むのか訳がわからんです。
                オープンソースにしたいならドライバモジュールをソース含めて公開すればいいだけでは?

              • by Anonymous Coward

                なぜってその方法は面倒だからさ。

              • by Anonymous Coward
                具体的には、ドライバーをカーネルツリーにマージしてもらわないと
                1.ドライバーを利用してもらえない
                2.ドライバーの導入で手間がかかって敬遠される
                3.ドライバーを自社サイトで配布する必要がある
                4.ドライバーのバグを発見した人が、自社サイトに送ってくる
                5.送られてきたパッチを精査したりマージするとか自社で管理する必要が生じる。
                6.そのへんが滞ったりすると、そのハードウェア自体の評判が落ちる。

                実際、Linux系OSでは、かなり長いこと
                ATIの純正ドライバーに不満を抱えている人がいると思うんですよね。
                PentiumM前後に、Radeon搭載ノートPCが多かったことも、逆にマイナスになっている気が…

                なお、ATI(AMD),NVIDIAは純正ドライバーを公開していますが
                それとは別に、カーネルツリーにはOSSのドライバーが存在しています。
                intelは大半のGPUについて、OSSのドライバーを寄贈しているようです。
        • by Anonymous Coward

          この状況は、サードパーティ周辺機器のドライバ拡充の障害になっていると思うのですが、なんで疎結合のI/F仕様を定めないんですかね。

          • >この状況は、サードパーティ周辺機器のドライバ拡充の障害になっていると思うのですが、なんで疎結合のI/F仕様を定めないんですかね。

            「そんなものを要求する暇があるなら、ソースコード公開しろ」と言うのが、LinuxでありGPLでありのポリシーですから。

            実際、一度ドライバのソースコードをリリースすれば、カーネルのメジャーヴァージョンが上がっても、余程作法の悪いドライバ以外は大抵はコンパイルが通るし、通らなくても数十行のパッチで問題なく動く場合がほとんどだと思いますよ。

            # 勿論、商業レベルで確実に動作しますよ。と言うテスト工数を含めた保証は又、別の話。

            親コメント
            • by Anonymous Coward
              疎結合のI/F仕様の要求とソースコードの公開は別の話なんじゃないかなぁ…。
              話が噛み合ってないような印象。

              要求しようがしまいが、ソースコードの公開は常に要求されているわけだし、
              ソースコードを公開したところで、カーネル側がそれに合わせてくれるわけでもない。

              再コンパイルやパッチで、ドライバ側がカーネルに合わせなければいけないことに変わりはなく、
              それなら極力手間がかからないように、疎結合のI/F仕様を定めてくれという要求は、
              至極真っ当だと思うのですが。
      • by Anonymous Coward

        当時はDRMとか無かったけど、NT4.0で見た悪夢やRage Furyを思い出す。
        変なことやってないことを祈るのみ。。

        DRMがカーネル側に振られてるのは利権者の政治臭く感じるのは私だけですかね。

        • by Anonymous Coward

          バイナリブロブはカーネルに入れないことになっている。そこでどうしてもDRMに対応させるためにこうしたんだろ。

        • by Anonymous Coward

          >DRMがカーネル側に振られてるのは利権者の政治臭く感じるのは私だけですかね。

          なんの利権?

        • by Anonymous Coward

          そもそも名前が…絶対わざとかぶらせてるだろ

      • by Anonymous Coward

        つまりsystemd-drmの出番というわけだな!

      • by Anonymous Coward

        Windowsは太古のNT4で、まさにパフォーマンスのために一度カーネルモードに移って、Vistaからやっぱ安定性がダメだということでユーザーモードに戻ってきたので、2周半くらい遅れていますね。

    • by Anonymous Coward
      誰かmonothiliな人、教えて!というわけですね
    • by Anonymous Coward

      Linuxはハードウェアに合わせてカーネルを作ります
      Windowsはカーネルに合わせてハードウェアを作ります

    • by Anonymous Coward

      オープンソースなのでドライバを公式のソースコードに突っ込んどけばカーネルの開発者がカーネルのコードを変更する際にドライバに配慮してくれるかもしれない。
      ちなみにカーネルが変更されるとドライバのリビルドが必要になる問題はdkmsで解決する。

  • by Anonymous Coward on 2015年07月11日 3時28分 (#2845697)

    コードを無条件で信用しているわけないだろうし

    • by Anonymous Coward

      もしかしてカーネルビルドがさらに遅くなる、なんてことにならないの?

    • by Anonymous Coward
      自分が入れてもらった分はLKMLでボコボコに叩かれてまふ
typodupeerror

Stableって古いって意味だっけ? -- Debian初級

読み込み中...