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

Linus Torvalds氏、ARM用コードに噛み付く 85

ストーリー by hylom
急速な普及の裏で開発者は大変だ 部門より

eggy 曰く、

LinuxカーネルのメンテナーLinus Torvalds氏がARMに対して噛み付いており、せっかく整理統合が進みつつあるARM用Linuxカーネルの動きを脅かしているとのこと(本家/.IT World記事)。

3月31日、LinusはLinuxカーネルのメーリングリストに宛てたメッセージで「つまり私が言いたいのは、ARMデバイス用のドライバを闇雲にLinuxカーネルに加えるべきでないということだ」「なぜなら、それは動かないからだ。長期的に見れば、これらの変更はメンテナンスできないゴミだ。」「カーネル内に組み込むべきではない」と述べており、4月18日には「無意味なプラットフォームのコードが果てしない程あるというのは問題だってことに皆気がつかなくてはならないし、唯一私にできることといったら『直す努力を怠るようなら、お前達から離れるぞ』と言うことだけだ。最終的にはそうすることになるだろうが」と強気な姿勢を崩していない。

ARM用Linuxカーネルを開発するLinaroのDavid Rusling氏によれば、新カーネルに対しておよそ70,000ものARMコードが追加されるのに対し、x86コードはたったの5,000程しか追加されていないとのこと。Torvalds氏の苛立ちはもっともであると思われる。

この背景には、最近のARM搭載デバイスの急増と、組み込み向けシステム開発企業によるLinuxへの貢献の増加がある。デバイスベンダーはLinuxカーネルにこれらのデバイス固有の改良を加え、それをLinuxカーネルのメインツリーに入れようとするが、そのようなコードは長期的に見ればやがてメンテナンスされなくなる可能性が高い。また、コミュニティによって十分にレビューされていないコードがメインツリーに入ってしまう可能性もある。Linus氏の苦言は、このような状況を踏まえたもののようだ。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 汎用と固有 (スコア:4, 参考になる)

    by Anonymous Coward on 2011年06月22日 19時16分 (#1974751)

    やはり
    >デバイスベンダーはLinuxカーネルにこれらのデバイス固有の改良を加え、
    ここが重要だね。
    汎用的なARMのコードではなくてある特定の物に依存するコードを追加しようって言うのがね。
    そうなるとLinuxカーネルがメーカ側の身勝手さでとんでもない煩雑としてカーネルソースになる可能性があるよね。

    そうならないためにMSは
    http://eetimes.jp/ee/articles/1106/06/news110.html [eetimes.jp]
    Win8で対応するARMベンダーを固定する気でいるのでしょうね。

    • by Anonymous Coward on 2011年06月22日 19時36分 (#1974761)

      要はarch/arm/の下が混乱してるってことでしょう。

      arch/arm/march-xxxだったかな、固有のコードが放りこまれて太り続けてる。
      ARMはSoCがメインで、SoCが持つペリフェラルをイネーブルにするようなコードも
      arch/armの下に放りこまれてたりするのは確か。
      そんなのはドライバでやれよとイライラするのもわからないではない気はする。

      もっともarch/x86の下もそのようなコードはあったりもするんで、つまりは
      armファミリは数が大ギルというのも一因かと。

      親コメント
      • by Anonymous Coward on 2011年06月22日 21時55分 (#1974850)

        混乱するのは何も arch/arm/ の下だけじゃない。
        恐ろしいことに、CPU だけでなくボード毎の回路の都合で drivers/ の下すらも混乱してしまうんです。

        たとえば SD カードスロット。
        ある ARM 系 CPU ベンダの提供するコードでは内蔵 SD コントローラのデバドラに、PMIC デバイスを使用することを前提としたカードスロットの電源制御コードが書かれていたりします。
        が、それはそのベンダの評価ボードがたまたまそういう構成だ、というだけのこと。
        デバドラ制御の PMIC デバイスなんか使わなくても GPIO 一本でスロットの電源制御できるように回路構成することも出来ます。
        それどころか、SDカード/SDIOモジュール嵌め殺しの構成なら電源を 3.3V 直結して、そもそも電源制御することができないようにも回路構成できるんです。

        で、そういったボード毎の微妙な差異を drivers/ の下にある、CPU 内蔵のペリフェラルモジュールのデバドラで吸収したりするんですよ。
        抽象化が足りていないというかレイヤ分けがなってないというか……

        親コメント
      • Re:汎用と固有 (スコア:1, 参考になる)

        by Anonymous Coward on 2011年06月22日 20時16分 (#1974789)

        そういえばx86を64bitに拡張しようとしたときAMDが先陣切って行ってインテル側が後からAMDの拡張と別に行おうとして
        マイクロソフトから待ったがかかって結局AMDと同じ実装をする羽目になったことを思い出した。
        まぁそれのおかげでx86-64は統一された拡張になったんだよね。
        あれがなかったらx86のカーネルもARMほどではなくて2社だけど多少は大変な状況になっていたかもね。

        余談だけど
        インテルは当時とはx86であるIA32は切り捨ててIA64に移行しようとして大失敗。
        インテルにのったHPのAlphaCPU開発チームもそれにつられて大失敗。
        で先日の
        http://srad.jp/article.pl?sid=11/06/17/1936212 [srad.jp]
        このニュースに行き着くと言うことですね。

        親コメント
        • by Anonymous Coward

          >インテルは当時とはx86であるIA32は切り捨ててIA64に移行しようとして大失敗。
          >インテルにのったHPのAlphaCPU開発チームもそれにつられて大失敗。

          その前に、DECのAlpha開発チームの一部はDECがCompaqに買収された際に流出し、AMDでAthlonを作っていました。そして、amd64へとつながっていく。
          Slot Aが形はIntelのSlot 1だったけど、電気的にはAlphaのEV6プロトコルだったというのも有名な話。結局IntelもhpもAlphaチームを活かせなかったね。
          http://pc.watch.impress.co.jp/docs/article/981104/kaigai02.htm [impress.co.jp]

          • Re:汎用と固有 (スコア:1, 参考になる)

            by Anonymous Coward on 2011年06月23日 1時31分 (#1974958)
            そのK7 AthlonのEV6プロトコルがSMP構成でボトルネックとなり、K8以降では採用されなかったんだよね。

            4プロセッサとか複数メモリコントローラなどのハイエンドな構成ならスケーラビリティが生きたのかもしれないが、
            2プロセッサで1個だけのメモリコントローラの場合、バンド幅はあるけれどもレイテンシが非常に大きくて、残念なことに。
            親コメント
          • by Anonymous Coward
            AlphaはHPに買収される前に続投しないことが決定していたからね。
            そもそも活かす予定は無かったと。

            DECの系譜は、とことん商売下手だからね。
            Athlonだって成功したけど、商売的に大成功とは言い難いし。
            もっとも、最近のAMDは開発者はIBMの系譜が強いらしいが、、

            IA32の拡張に継ぐ拡張は、短期にはいいけど、長期的には袋小路い陥りそうでイヤンな感じ。
            まじでデスクトップもARMも追い落とされたりするかもね。
        • by Anonymous Coward
          > インテルは当時とはx86であるIA32は切り捨ててIA64に移行しようとして大失敗。

          誤解していますよ。
          IA64はIA32とバイナリ互換です。

          少なくとも私はItanium機にMS-DOSの起動FDをつっこんで、ちゃんと起動するのを見ましたし、
          32ビットの既存のWindowsアプリが動作するのも見ましたよ。
          • by T.SKG (20663) on 2011年06月23日 9時31分 (#1975049) 日記
            Itaniumには、互換性のために IA32を処理する一種のエミュレータ機能が付加されていましたが、
            処理能力はIA64で動作するよりずっと劣ったものです。それも、McKinley コアまでで、Merced コアの Itanium2 では、廃止になったんじゃないかな。
            親コメント
          • by nox_dot (11614) on 2011年06月23日 2時27分 (#1974974) 日記

            それは、IA32エミュレータ上で動いているのではないでしょうか。

            親コメント
            • by Anonymous Coward
              いや、IA-64は仕様としてIA-32のアプリケーションを(OSのサポートがあれば)実行できるようになっているざます。
              IA-32のOSを実行できるという規定はありません。
              インテルのマニュアルを参照してください。「IA-64 アプリケーション・デベロッパーズ・ アーキテクチャ・ガイド」

              MS-DOSのフロッピーから起動したというのは、たまたまその機種がサポートしていたからではないでしょうか。
      • by Anonymous Coward
        ARMは各種ペリフェラルを組み合わせたSoCが多数存在し、それぞれペリフェラルの互換性が無い以上、固有のコードを追加するほかありません。

        これがx86なら、互換性の無いチップセットやペリフェラルが次々と増え続けているようなものです。

        Linusさんが噛み付く相手は、ソフト開発者ではなくARM SoCメーカーであるべきと思うのですw
        • by Anonymous Coward

          いや開発者もかみつく相手だろ。
          固有な部分をカーネルソースのツリーに統合仕様としているんだから
          開発者は自サイトでカーネルのパッチとして配布すればいい。

    • by Anonymous Coward
      ARMはプロセッサの名前であって、ARMを積んだ規格化されたボードじゃないんだから混乱するのは当然じゃない?
      同じARMコアを搭載している組込用プロセッサでも、内蔵のペリフェラルは各メーカー千差万別なんだから、それをみんな真面目にLinuxでサポートしようとしたら大変な事になるのでは?

      >そうならないためにMSは
      >http://eetimes.jp/ee/articles/1106/06/news110.html
      >Win8で対応するARMベンダーを固定する気でいるのでしょうね。

      対応するARMプロセッサのバリエーションを固定してもボードの仕様の相違が出てくる可能性はあるわけで、当然MicrosoftはWindows8対応ARMボードの仕様をガッチガッチに固めてメーカーに提供することになるのかな?(そうなると他社製品との差別化がやりにくくなって面白くないだろうけど)
      • by Anonymous Coward on 2011年06月23日 5時12分 (#1974991)
        WindowsにはHAL(Hardware Abstract Layer)があるじゃないか。
        世の中みんなAT互換機だらけで、カスタムHALを忘れてるけれども、今までも幾つかはカスタムHALが作られてますよ。
        親コメント
        • by greentea (17971) on 2011年06月23日 12時14分 (#1975158) 日記

          LinuxにあるHALやudevとは違うの?

          --
          1を聞いて0を知れ!
          親コメント
          • カーネル側の独立したデバイスドライバが用意されていてこそのHALであり、udev。
            今回はSoCとしてくっつけてある部分のデバイスドライバを独立させて、機能部位単位でそれぞれのapiを統一させましょう。と言う機運がなくて、しかもどういう経緯かはともかくドライバをカーネルの中枢に最も近い所に位置させるのがふつーになってしまったから、同じCPUコアなのにぐちゃぐちゃ(><)と言う状況みたいですね。

            これは、Linus的にキレて当然だと思うんですよねぇ…ソフトウェアを書く作法として綺麗さがないにも程があるということで…

            # でも、SoCに密着した形でカーネルカスタマイズしてるベンダさんの方は「動くんだからいーじゃん((´∀`))ヶラx2」って所なんでしょうね。えぇ…

            親コメント
  • そりゃあそうでしょ (スコア:2, おもしろおかしい)

    by Anonymous Coward on 2011年06月22日 22時13分 (#1974864)

    何か勘違いしているしったか君が多いけど、ARMってのは基本プロプラなんだわ。オプソ推進のIntelやAMDとは大違い。
    NVIDIAがARM系のチップやCPUを統合するとか言いだしたのも、プロプラってのがNVIDIAの方針とピッタリだったってのが大方の見方。

    プロプラだからテストもクソもない、使わない人にとってみれば完全なるゴミコード。そんなもんでこれ以上カーネルサイズ増やすなよ。
    Linusからしたらそう言いたい気持ちだろうし、ぶっちゃけARMコードをカーネルビルドに加えた時点で「taints kernel」印にしたいところだろうぜ。

    だがしったか君達は「Intelを叩く俺は物知り」という勘違いをしているので、今回のような場合は皆総じて「Linusは独裁者」といった類のしょうもないコメントばかりする。
    ここまで20近いコメントがありながら、その全てが「x86だってゴミ」とか、「GPL汚染が」とか、「Linuxのドライバの実装方法が」とか、しまいには関係のないx86_64話だぜ? あほかと。

    「LinusがARMコードばっかマージしようとする事に激怒してる?」「ああプロプラだからね」
    たったこれだけで説明終了なのに何アホコメント連発してんだ? 反省しろと。

    • by Anonymous Coward

      タイトルからして恣意的だよなぁ。噛み付くとか。

      まぁ、大人の事情があるんでしょ。お金とかお金とかお金とか。

    • by Anonymous Coward
      だいたい、同意。
      オープンソースって、それを動かせるハードウェアがあって、皆が幸せになれるのであって、 kernel.org にマージされてソースはあるけど、ハードはディスコン(生産中止)な状態だっ たら、そのソースは何かの参考にはなるだろうけど、本来の姿じゃない感じがする。

      私がよく利用する ppc (今は powerpc か)も、CPU の種類が多くて混沌としているけど、 それを酷くした状態なのだろうか?と想像してみる。
      評価ボード用のカスタム kernel という立場に留め、kernel.org にマージする必要はない と思う。

      • by Anonymous Coward
        >評価ボード用のカスタム kernel という立場に留め、kernel.org にマージする必要はないと思う。
        今回はARMの話だから、各ベンダ毎にカーネルイメージを用意しているところもあるだろうし、まあ当てはまらないかもしれんが、
        とはいえ「kernel.org(Linus' treeとかmainstream kernelとかmainlineとか)にあらずんばカーネルにあらず」というユーザも多いので、極力マージしてくれる方が幸せなんだがな。
        「パッチ当てるのはなんか不具合が入り込みそうで嫌だ」と考える奴が(組み込みメーカでも意外と)多いのだ...

        (親々米には概ね同意)
  • 確かにカーネルは「デバイスドライバーが無ければただのゴミ」ですが
    デバイスドライバーをカーネルのソースに混ぜ込んで使っている現状が、おかしいと思います。
    ここは、ドライバーのソースは別管理にして、
    http://www.kernel-drivers.org/ [kernel-drivers.org]
    というサイトでも作って別に管理したらどうでしょうか?
    カーネルに組み込むものは、同時にビルドして埋め込む様にするとか、
    モジュールで使うモノは、別にビルドして別パッケージで配布するとか、
    いろいろと、工夫は出来ると思います。
  • 要するに (スコア:2, すばらしい洞察)

    by s.o.b (37712) on 2011年06月23日 11時20分 (#1975111)
    ハード実装依存コードを山ほど入れて
    誰がメンテするの?
    そもそもARMのアーキテクチャのコードじゃなくて
    ARM CPUを載せたボードのコードでしょ
    その組み込み機器かモバイルツールか何かの
    ベンダしかメンテできないんじゃないの?
    kernelのarchでやらないでよ

    ってことでしょ
  • メンテされてないゴミコードはx86にだって結構ある印象。
    # しばらく壊れたまんまだったので代替を開発してたら元のコードが急にメンテナンスされるようになってみたり...。

  • by Anonymous Coward on 2011年06月22日 19時20分 (#1974753)
    サーバーの電源ケーブルをネズミにかじられた時は大変だったなぁ・・・
    • by Anonymous Coward
      ケーブルではなくコードと書くべきだったと思います。
  • ARMはライセンスと命令セットだけで実物は全部別物でしょ?似てるけど違うよ!ってことにすればいいじゃん。IntelとAMDくらい似てるのとは事情が違うように思える。
    まあそれでもLinus的には名前変えたってダメなもんはダメって言うんだろうけど
    • by Anonymous Coward

      >ARMはライセンスと命令セットだけで実物は全部別物でしょ?
      調べてないんであれだけど、今回マージしようとしてる7万のARMコードのうち、大半がAndroid向けだったりしないかな
      2009年12月に削除した絡みで

  • by Anonymous Coward on 2011年06月22日 19時40分 (#1974766)

    GPLやめてBSDにすればいいんだよ。

  • by Anonymous Coward on 2011年06月22日 20時09分 (#1974786)

    よくわからないのですが、Linuxはカーネルにドライバの組み込みが必要なの?
    ある会社があまり普及しなさそうな独自のデバイスを開発して、ソースツリーにマージしたら、
    全世界のLinuxユーザーのカーネルにそれが届くの?

    普通はドライバってデバイスの利用者が自分だけでロードするんじゃないかって思ってた。
    違うの?

    • IBM PC/AT互換機では、いろんな機器があるとはいえ
      機器の部品化が進んでいて、同じ部品が多くの機器で使われるのが普通だと思います。

      反面ARM搭載機器は、クローズドなハードウェアで
      そのある一社のハードウェアにおいて、配線とか制御方法の都合で
      依存したドライバーが必須となったりするんだと思います。
      利用するのが一社であれば、メンテナンスが止まる可能性も高いし
      そもそも、使い続ける人がいるのかも怪しいと考えられます。

      多くのARM搭載機器では、OSやカーネルの入れ替えは
      エンドユーザーが自由にできるものでは無いでしょうし…
      書いたものは、提出するのが自然と考えるのかもしれませんが…
      それをマージするかしないか?品質に問題が無いか?
      そこを審査できる組織になっていないという問題なんだと思います。

      Linuxでは、カーネルツリーに大量のデバイスドライバーがマージされていますが
      実際に利用されるカーネルでは、ほとんどがモジュールとして切り離されています。
      (メモリー圧迫を防いだり、ロード時間の短縮に貢献します)
      一部のドライバーはカーネル内に組み込まれて、起動時からの重要な役割を担います。

      この選択肢は、一般的にはディストリビューションとして判断されています。
      必要であればカーネル再構築として、自分で変えることもできます。

      このカーネルツリーに大量のドライバーをマージした管理方法は
      必要なデバイスドライバーの導入について、大幅な効率向上を実現しています。

      FedoraやUbuntuでは半年ごとにインストールディスクが更新されますが
      これは、比較的新しい機器についても
      ドライバーを自動認識で利用できることが多いという利点につながっています。
      親コメント
      • by Anonymous Coward
        FreeBSDやNetBSDでは、CPUアーキテクチャは一緒だけど、互換性のないハードウェア
        たとえば、同じx86でも、AT互換機、PC-9800、FM-R
        たとえば、同じ68kでも、Mac、Amiga、Sun3、X68000
        いろいろ、あったよね。どうしてたんだろう。
    • by Anonymous Coward on 2011年06月22日 20時21分 (#1974793)

      現行のカーネルのライセンス形態であるGPLv2に矛盾しないライセンス形態であることと、カーネル側のアップデートに常時追随できるだけのメンテナが存在することの両方が満たされれば、ってところですかね。

      もちろんGPLv2と矛盾するカーネルドライバの存在が禁止されてるわけではありません (Windows ほどではありませんが、現に多数のドライバがあります) 。

      親コメント
    • 機器独自のデバイスにも、セットアップコード・initrdデバイス・lib/modulesデバイス・マージされてないドライバ・プロプライエタリドライバとか結合度に種類あるから。 x86は基本全部入りでカーネルビルドするけど、組み込みはカスタムビルドするし
      親コメント
  • by Anonymous Coward on 2011年06月22日 21時51分 (#1974845)
    パッチ爆弾送り付けとけば、実質的にGPL回避できるって事か。
  • by Anonymous Coward on 2011年06月22日 22時02分 (#1974853)
    ならないならない
  • by Anonymous Coward on 2011年06月22日 22時03分 (#1974855)
    プラットフォーム固有のドライバも何とかならないのか
    明らかに組み込み用途専用のドライバが出てきて2.6系カーネルは訳分からん
typodupeerror

人生の大半の問題はスルー力で解決する -- スルー力研究専門家

読み込み中...