Linus Torvalds氏、ARM用コードに噛み付く 85
急速な普及の裏で開発者は大変だ 部門より
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, 参考になる)
やはり
>デバイスベンダーはLinuxカーネルにこれらのデバイス固有の改良を加え、
ここが重要だね。
汎用的なARMのコードではなくてある特定の物に依存するコードを追加しようって言うのがね。
そうなるとLinuxカーネルがメーカ側の身勝手さでとんでもない煩雑としてカーネルソースになる可能性があるよね。
そうならないためにMSは
http://eetimes.jp/ee/articles/1106/06/news110.html [eetimes.jp]
Win8で対応するARMベンダーを固定する気でいるのでしょうね。
Re:汎用と固有 (スコア:1, 興味深い)
要はarch/arm/の下が混乱してるってことでしょう。
arch/arm/march-xxxだったかな、固有のコードが放りこまれて太り続けてる。
ARMはSoCがメインで、SoCが持つペリフェラルをイネーブルにするようなコードも
arch/armの下に放りこまれてたりするのは確か。
そんなのはドライバでやれよとイライラするのもわからないではない気はする。
もっともarch/x86の下もそのようなコードはあったりもするんで、つまりは
armファミリは数が大ギルというのも一因かと。
Re:汎用と固有 (スコア:4, 興味深い)
混乱するのは何も arch/arm/ の下だけじゃない。
恐ろしいことに、CPU だけでなくボード毎の回路の都合で drivers/ の下すらも混乱してしまうんです。
たとえば SD カードスロット。
ある ARM 系 CPU ベンダの提供するコードでは内蔵 SD コントローラのデバドラに、PMIC デバイスを使用することを前提としたカードスロットの電源制御コードが書かれていたりします。
が、それはそのベンダの評価ボードがたまたまそういう構成だ、というだけのこと。
デバドラ制御の PMIC デバイスなんか使わなくても GPIO 一本でスロットの電源制御できるように回路構成することも出来ます。
それどころか、SDカード/SDIOモジュール嵌め殺しの構成なら電源を 3.3V 直結して、そもそも電源制御することができないようにも回路構成できるんです。
で、そういったボード毎の微妙な差異を drivers/ の下にある、CPU 内蔵のペリフェラルモジュールのデバドラで吸収したりするんですよ。
抽象化が足りていないというかレイヤ分けがなってないというか……
Re:汎用と固有 (スコア:1, 参考になる)
cf. x86: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tre... [kernel.org]
MMCはこの辺かね。大分ごちゃごちゃしてきているのはわかる。
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tre... [kernel.org]
Re: (スコア:0)
うわぁ…
Re:汎用と固有 (スコア:1, 参考になる)
そういえば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]
このニュースに行き着くと言うことですね。
Re: (スコア:0)
>インテルは当時とは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, 参考になる)
4プロセッサとか複数メモリコントローラなどのハイエンドな構成ならスケーラビリティが生きたのかもしれないが、
2プロセッサで1個だけのメモリコントローラの場合、バンド幅はあるけれどもレイテンシが非常に大きくて、残念なことに。
Re: (スコア:0)
そもそも活かす予定は無かったと。
DECの系譜は、とことん商売下手だからね。
Athlonだって成功したけど、商売的に大成功とは言い難いし。
もっとも、最近のAMDは開発者はIBMの系譜が強いらしいが、、
IA32の拡張に継ぐ拡張は、短期にはいいけど、長期的には袋小路い陥りそうでイヤンな感じ。
まじでデスクトップもARMも追い落とされたりするかもね。
Re: (スコア:0)
誤解していますよ。
IA64はIA32とバイナリ互換です。
少なくとも私はItanium機にMS-DOSの起動FDをつっこんで、ちゃんと起動するのを見ましたし、
32ビットの既存のWindowsアプリが動作するのも見ましたよ。
Re:汎用と固有 (スコア:2)
処理能力はIA64で動作するよりずっと劣ったものです。それも、McKinley コアまでで、Merced コアの Itanium2 では、廃止になったんじゃないかな。
Re:汎用と固有 (スコア:2)
調べ直したつもりが、出鱈目を書いてしまった。
(Merced が来るぞと、大騒ぎをしたんですから、初代ですよね)
Re:汎用と固有 (スコア:1)
それは、IA32エミュレータ上で動いているのではないでしょうか。
Re: (スコア:0)
IA-32のOSを実行できるという規定はありません。
インテルのマニュアルを参照してください。「IA-64 アプリケーション・デベロッパーズ・ アーキテクチャ・ガイド」
MS-DOSのフロッピーから起動したというのは、たまたまその機種がサポートしていたからではないでしょうか。
Re:汎用と固有 (スコア:1)
失礼しました。
ご指摘の通り、当初ハードウエアでサポートされていたものの、エミュレータのほうが性能が高く、後にハードウエアサポートが廃止されたのでした。
すみませんでした。
Re: (スコア:0)
これがx86なら、互換性の無いチップセットやペリフェラルが次々と増え続けているようなものです。
Linusさんが噛み付く相手は、ソフト開発者ではなくARM SoCメーカーであるべきと思うのですw
Re: (スコア:0)
いや開発者もかみつく相手だろ。
固有な部分をカーネルソースのツリーに統合仕様としているんだから
開発者は自サイトでカーネルのパッチとして配布すればいい。
Re:汎用と固有 (スコア:2, すばらしい洞察)
それ、リーナスが書くべきなんでしょうか?
必要とする人=ARMの開発者が書くものなんじゃ?
Re: (スコア:0)
同じARMコアを搭載している組込用プロセッサでも、内蔵のペリフェラルは各メーカー千差万別なんだから、それをみんな真面目にLinuxでサポートしようとしたら大変な事になるのでは?
>そうならないためにMSは
>http://eetimes.jp/ee/articles/1106/06/news110.html
>Win8で対応するARMベンダーを固定する気でいるのでしょうね。
対応するARMプロセッサのバリエーションを固定してもボードの仕様の相違が出てくる可能性はあるわけで、当然MicrosoftはWindows8対応ARMボードの仕様をガッチガッチに固めてメーカーに提供することになるのかな?(そうなると他社製品との差別化がやりにくくなって面白くないだろうけど)
Re:汎用と固有 (スコア:2, 興味深い)
世の中みんなAT互換機だらけで、カスタムHALを忘れてるけれども、今までも幾つかはカスタムHALが作られてますよ。
Re:汎用と固有 (スコア:1)
LinuxにあるHALやudevとは違うの?
1を聞いて0を知れ!
BIOSやEFIがないが故の悲劇?(Re:汎用と固有 (スコア:2, 興味深い)
カーネル側の独立したデバイスドライバが用意されていてこそのHALであり、udev。
今回はSoCとしてくっつけてある部分のデバイスドライバを独立させて、機能部位単位でそれぞれのapiを統一させましょう。と言う機運がなくて、しかもどういう経緯かはともかくドライバをカーネルの中枢に最も近い所に位置させるのがふつーになってしまったから、同じCPUコアなのにぐちゃぐちゃ(><)と言う状況みたいですね。
これは、Linus的にキレて当然だと思うんですよねぇ…ソフトウェアを書く作法として綺麗さがないにも程があるということで…
# でも、SoCに密着した形でカーネルカスタマイズしてるベンダさんの方は「動くんだからいーじゃん((´∀`))ヶラx2」って所なんでしょうね。えぇ…
そりゃあそうでしょ (スコア:2, おもしろおかしい)
何か勘違いしているしったか君が多いけど、ARMってのは基本プロプラなんだわ。オプソ推進のIntelやAMDとは大違い。
NVIDIAがARM系のチップやCPUを統合するとか言いだしたのも、プロプラってのがNVIDIAの方針とピッタリだったってのが大方の見方。
プロプラだからテストもクソもない、使わない人にとってみれば完全なるゴミコード。そんなもんでこれ以上カーネルサイズ増やすなよ。
Linusからしたらそう言いたい気持ちだろうし、ぶっちゃけARMコードをカーネルビルドに加えた時点で「taints kernel」印にしたいところだろうぜ。
だがしったか君達は「Intelを叩く俺は物知り」という勘違いをしているので、今回のような場合は皆総じて「Linusは独裁者」といった類のしょうもないコメントばかりする。
ここまで20近いコメントがありながら、その全てが「x86だってゴミ」とか、「GPL汚染が」とか、「Linuxのドライバの実装方法が」とか、しまいには関係のないx86_64話だぜ? あほかと。
「LinusがARMコードばっかマージしようとする事に激怒してる?」「ああプロプラだからね」
たったこれだけで説明終了なのに何アホコメント連発してんだ? 反省しろと。
Re: (スコア:0)
タイトルからして恣意的だよなぁ。噛み付くとか。
まぁ、大人の事情があるんでしょ。お金とかお金とかお金とか。
Re: (スコア:0)
オープンソースって、それを動かせるハードウェアがあって、皆が幸せになれるのであって、 kernel.org にマージされてソースはあるけど、ハードはディスコン(生産中止)な状態だっ たら、そのソースは何かの参考にはなるだろうけど、本来の姿じゃない感じがする。
私がよく利用する ppc (今は powerpc か)も、CPU の種類が多くて混沌としているけど、 それを酷くした状態なのだろうか?と想像してみる。
評価ボード用のカスタム kernel という立場に留め、kernel.org にマージする必要はない と思う。
Re: (スコア:0)
今回はARMの話だから、各ベンダ毎にカーネルイメージを用意しているところもあるだろうし、まあ当てはまらないかもしれんが、
とはいえ「kernel.org(Linus' treeとかmainstream kernelとかmainlineとか)にあらずんばカーネルにあらず」というユーザも多いので、極力マージしてくれる方が幸せなんだがな。
「パッチ当てるのはなんか不具合が入り込みそうで嫌だ」と考える奴が(組み込みメーカでも意外と)多いのだ...
(親々米には概ね同意)
Re: (スコア:0)
あんまり擁護したくない気分だけど、実際LinusとLinuxについて無知すぎるコメント多すぎないか
LinuxがARMをサポートしてないと思ってる奴さえいる予感
そもそもドライバーをカーネルのソースから分離するべきかと (スコア:2)
デバイスドライバーをカーネルのソースに混ぜ込んで使っている現状が、おかしいと思います。
ここは、ドライバーのソースは別管理にして、
http://www.kernel-drivers.org/ [kernel-drivers.org]
というサイトでも作って別に管理したらどうでしょうか?
カーネルに組み込むものは、同時にビルドして埋め込む様にするとか、
モジュールで使うモノは、別にビルドして別パッケージで配布するとか、
いろいろと、工夫は出来ると思います。
要するに (スコア:2, すばらしい洞察)
誰がメンテするの?
そもそもARMのアーキテクチャのコードじゃなくて
ARM CPUを載せたボードのコードでしょ
その組み込み機器かモバイルツールか何かの
ベンダしかメンテできないんじゃないの?
kernelのarchでやらないでよ
ってことでしょ
x86だって...なぁ...。 (スコア:1)
メンテされてないゴミコードはx86にだって結構ある印象。
# しばらく壊れたまんまだったので代替を開発してたら元のコードが急にメンテナンスされるようになってみたり...。
Re:x86だって...なぁ...。 (スコア:1)
とはいえ、ある程度はこなれてるコードの比率は高そうだし、統廃合のときのこととかもあってある程度は枝きりしている...印象。
すくなくとも「自分がよく見てるとこと同程度はレビューしてこなれたものマージしろ」くらいは言いたくなるだろうな、とは思った。
# ...今のx86ってほかのアーキと比べて、どれくらいきれいなんだろうか
M-FalconSky (暑いか寒い)
Re:x86だって...なぁ...。 (スコア:3, 参考になる)
あんまり使う人がいない機能は壊れてるのがそのまま入ってることもある。要は過去に動いてたものをマージしたときに壊してそのままという。マージする人は自分が書いたところを中心にチェックするからね。だからこなれててもダメなこともあるんだ。そのうちメンテナンスされるだろうけど作る方に比べてそういう副作用の修正は恐ろしく遅い。
# そして元コメで書いた代替機能も2.6.30あたりでぶっ壊されて直したら2.6.35でまたぶっ壊された模様。もうやだ。
Re:x86だって...なぁ...。 (スコア:1)
> # そして元コメで書いた代替機能も2.6.30あたりでぶっ壊されて直したら2.6.35でまたぶっ壊された模様。もうやだ。
それはひどい...
M-FalconSky (暑いか寒い)
ふと思い出した (スコア:0)
Re: (スコア:0)
ARMじゃなくて固有アーキテクチャにすればいんじゃないの (スコア:0)
まあそれでもLinus的には名前変えたってダメなもんはダメって言うんだろうけど
Re: (スコア:0)
>ARMはライセンスと命令セットだけで実物は全部別物でしょ?
調べてないんであれだけど、今回マージしようとしてる7万のARMコードのうち、大半がAndroid向けだったりしないかな
2009年12月に削除した絡みで
簡単じゃないか (スコア:0)
GPLやめてBSDにすればいいんだよ。
ドライバがカーネルに必要なの? (スコア:0)
よくわからないのですが、Linuxはカーネルにドライバの組み込みが必要なの?
ある会社があまり普及しなさそうな独自のデバイスを開発して、ソースツリーにマージしたら、
全世界のLinuxユーザーのカーネルにそれが届くの?
普通はドライバってデバイスの利用者が自分だけでロードするんじゃないかって思ってた。
違うの?
PCでは成功しているドライバー同梱の仕組み (スコア:3, 参考になる)
機器の部品化が進んでいて、同じ部品が多くの機器で使われるのが普通だと思います。
反面ARM搭載機器は、クローズドなハードウェアで
そのある一社のハードウェアにおいて、配線とか制御方法の都合で
依存したドライバーが必須となったりするんだと思います。
利用するのが一社であれば、メンテナンスが止まる可能性も高いし
そもそも、使い続ける人がいるのかも怪しいと考えられます。
多くのARM搭載機器では、OSやカーネルの入れ替えは
エンドユーザーが自由にできるものでは無いでしょうし…
書いたものは、提出するのが自然と考えるのかもしれませんが…
それをマージするかしないか?品質に問題が無いか?
そこを審査できる組織になっていないという問題なんだと思います。
Linuxでは、カーネルツリーに大量のデバイスドライバーがマージされていますが
実際に利用されるカーネルでは、ほとんどがモジュールとして切り離されています。
(メモリー圧迫を防いだり、ロード時間の短縮に貢献します)
一部のドライバーはカーネル内に組み込まれて、起動時からの重要な役割を担います。
この選択肢は、一般的にはディストリビューションとして判断されています。
必要であればカーネル再構築として、自分で変えることもできます。
このカーネルツリーに大量のドライバーをマージした管理方法は
必要なデバイスドライバーの導入について、大幅な効率向上を実現しています。
FedoraやUbuntuでは半年ごとにインストールディスクが更新されますが
これは、比較的新しい機器についても
ドライバーを自動認識で利用できることが多いという利点につながっています。
Re: (スコア:0)
たとえば、同じx86でも、AT互換機、PC-9800、FM-R
たとえば、同じ68kでも、Mac、Amiga、Sun3、X68000
いろいろ、あったよね。どうしてたんだろう。
Re:ドライバがカーネルに必要なの? (スコア:1, 参考になる)
現行のカーネルのライセンス形態であるGPLv2に矛盾しないライセンス形態であることと、カーネル側のアップデートに常時追随できるだけのメンテナが存在することの両方が満たされれば、ってところですかね。
もちろんGPLv2と矛盾するカーネルドライバの存在が禁止されてるわけではありません (Windows ほどではありませんが、現に多数のドライバがあります) 。
Re:ドライバがカーネルに必要なの? (スコア:1)
GPL回避の裏ワザ (スコア:0)
Re:GPL回避の裏ワザ (スコア:1)
ただのゴミコードになるって話では。
Re: (スコア:0)
GNU's Not Linux
そしてLinuxもマイクロカーネル化へ・・・ (スコア:0)
Re:そしてLinuxもマイクロカーネル化へ・・・ (スコア:2, 興味深い)
でもモノリシックカーネルなのが根本的な原因で、それが嫌ならマルチプラットフォームをやめるか、マイクロカーネルを提供するのが本筋な気がする。
モノリシックカーネル (スコア:0)
この流れなら、タネンバウム先生にコメントもらいにいくべきだろう。
プラットフォーム (スコア:0)
明らかに組み込み用途専用のドライバが出てきて2.6系カーネルは訳分からん