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

Linuxカーネルの"依存関係地獄"解消目指す「Fast Kernel Headers」 74

ストーリー by nagazou
地獄 部門より
ZDNetの記事によれば、数十年にわたって修正が加えられたLinuxカーネルの乱雑さを整理しようとする「Fast Kernel Headers」(カーネルヘッダー高速化)プロジェクトがあるそうだ。カーネル開発者の一人であるIngo Molnar氏が始めたもので、過去30年強で複雑化したLinuxカーネルのヘッダー階層とヘッダーの依存関係を全体的に整理したり作り直すという作業を行うらしい。ヘッダーファイルやincludeを整理することで、カーネルビルドを50~80%ほど高速化するというう野心的なプロジェクトとなっている(ZDNet Japan)。
  • by Anonymous Coward on 2022年01月13日 18時27分 (#4184161)

    カーネルのソースコード読んだことない人にはヘッダーの依存関係の整理とかいってもピンとこないんだろうな、とここまでの議論を読んでて思った。
    歴史的な事情で、同じファイルが3回も4回も読まれたり(読まれるだけで #ifdef で中身は破棄される)とか、相互依存になっているので片方読むともう片方も要不要にかかわらず自動で読まれるとか、役所の盥回しみたいにあちこちに飛ばされてなかなか本体にたどりつけなかったりとか、色々と悲しい状態になってる。
    みんな(誰かに)直して欲しいと思っていたところ。

    コード本体の全面書き直しみたいな話ではないので機能とか性能が変わるわけじゃないよ。

    ここに返信
    • by Anonymous Coward

      これで読みやすくなれば読む人増えるよ、ちょっとは
      いまだと迷子になる

    • by Anonymous Coward

      ヘッダーがとっ散らかってると、関数の動きがアレっと思って調べる時やパッチする時の影響範囲や依存関係調べるだけで大仕事になるし、本当に良かった。

      新規のコードじゃないのだ地味とか言われそうだけどとても大切で貢献度高いと思う。
      頑張って欲しい。
      下手に参加すると船頭多くして船山に登るになるから見守るしかないけど。

    • by Anonymous Coward

      BootlinがElixir Cross Referencerを作るくらいにはややこしいですね
      https://elixir.bootlin.com/linux/latest/source [bootlin.com]

    • by Anonymous Coward

      こういうのこそ機械学習による最適化が効きそうなもんなんだけど無理かな。

      • by Anonymous Coward

        人間による可読性を維持するのが難しかろう。

      • by Anonymous Coward

        機械学習は何らかの見本を元にそれっぽく良い感じのものを吐き出してくれるだけなので完璧な理論的整合性が求められるソースコードには使えないと思う
        せいぜいサジェスチョンが関の山

        • by Anonymous Coward

          少なくとも現状のソースコードがあるので、コンパイル後が現状と一致するかどうかという確認は簡単にできる。
          人間が修正したってどうせバグがゼロになることはないので、検証と修正が簡単な機械学習の方が早くコンパクトになると思う。
          そもそも「完璧な理論的整合性」なんて取れてないからこそ、大本のコメントのような現状があるのだし。

          ただ、別コメにもあるように可読性は両立できないだろうね。

          • by Anonymous Coward on 2022年01月13日 22時43分 (#4184303)

            や、比較対象は人間の修正じゃなくて修正専用プログラムです。
            Ingo Molnar氏はすでにper_task()というプログラムを使って数千のコミットの山を築いているので、機械学習がそれを上回れないと採用する意味がないです。

    • by Anonymous Coward

      そんなん普通にツールないの?
      `#ifdef`とかで条件変わること考えるとちょっと難しいけど、軽くPerlで処理して…の延長レベルに思えるけど。
      「実は依存してなかった」とかをきちんと判別するなら人力必須だろうが。

      • by Anonymous Coward

        ミネソタ大に逆ギレしてる開発者グループにまともなツールがあると思う?

  • /usr/include/errno.h から見始めるとファイルを5個とか6個とか開くことに

    /usr/include/errno.h
    → /usr/include/bits/errno.h
     → /usr/include/linux/errno.h
      → /usr/include/asm/errno.h
       → /usr/include/asm-generic/errno.h

    --
    [Q][W][E][R][T][Y]
    ここに返信
  • by Anonymous Coward on 2022年01月13日 16時29分 (#4184071)

    Rustでいちから作り直せ

    ここに返信
    • by Anonymous Coward

      ものになる頃にはFustが出ているよ

    • by Anonymous Coward

      記事2ページ目より

      Kroah-Hartman氏はMolnar氏の取り組みを認めた上で、「この件についてはスケジューラーの開発者らに任せたい。ただ私は依然として違和感を感じている。われわれは、Cの問題を回避しようとすると混乱を生み出してしまうのだ :)」とコメントしている。
      Kroah-Hartman氏の考えは間違っていない。RustをLinuxの第2言語にしようという動きの背後にある動機の1つは、まさにここにあるのだ。

      C資産を捨てるのは無理だけど、Rustも使おうって動きはあるみたいですね。
      C++のモジュールではどうか、って思うけど今からそっちに対応するよりはRustの方が現実的か……

    • by Anonymous Coward

      ビルド時間だけ考えるとrustにするとcよりは時間かかりそうな気もするけど....
      ただバグと脆弱性は少なくなりそう。

    • by Anonymous Coward

      それはMustか?

    • by Anonymous Coward

      Rust信者は各所で喚いてないでライブラリを充実させろよ

    • by Anonymous Coward

      その仕事はキミのものだ

    • by Anonymous Coward

      rustもいいけどc++もあるよ
      型情報をメタして保持するプレファイルにC++を使ったらどうかな?と
      .hppから複数の.hを生成するだけでなく勝手に編集された.hからみなし子要素の抽出にも使えるようなトランスレータを作ってさ

      • by Anonymous Coward

        素晴らしい。Linusが大絶賛しそう。

      • by Anonymous Coward

        ややもすると、clang(自体)のような、巨大なカーネルができあがってきそう
        なんでも書けちゃうからね、却って収拾つかなくなる

    • by Anonymous Coward

      Redux OS 愛でてれば?

  • by Anonymous Coward on 2022年01月13日 16時31分 (#4184075)

    この手のリファクタリングは往々にして事実上のfork、そして旧製品を超えられない。

    極度にカオス化した悪しき旧製品はバクすら仕様(バグに依存してる別製品が存在する)と化してるので
    様々な不条理も含めて完全コピーが必要(何もしない方がマシ)という自己矛盾に陥る。

    ここに返信
    • by Anonymous Coward on 2022年01月13日 17時19分 (#4184116)

      リファクタリングでバクを出すなんてカバだなあ。ちゃんとサイ設計しなよ。

    • by Anonymous Coward on 2022年01月14日 1時56分 (#4184368)

      牧歌的にみんな #include <linux/xxx.h> で ok、を越える様な修正提案には遠い様に読める。

      リポジトリを clone して、少し読んでみる。
      依存関係は整理される。だけどコードの背景にある決まりの複雑さは増す。一例を取り上げてみる。今まで、

      #include <linux/kref.h>

      と書けば、kref 関係の一切合切を使える様になった。まぁ、普通の発想だと思う。
      だけど、提案されている修正は、

      #include <linux/kref.h> /* kref に関係している型しか使えない。※1 */
      #include <linux/kref_types.h> /* kref に関係している型しか使えない(型しか使わない) */
      #include <linux/kref_api.h> /* kref に関係している一切合切(型定義と関数)を使える */

      ※1 移行作業緩和措置として CONFIG_FAST_HEADERS を「定義しなければ」、今まで通り #include <linux/kref.h> で一切合切使える。

      で、この流儀は当然のように drivers/* にも適応される。linux kernel を少しでも読んだことがあるなら、linux kernel のヘッダにはこれは型定義?関数?初期化子?と悩む定義がてんこ盛りだ(コンパイラの機械的な解釈は一意だけどね)。

      なんで、よほど強い強制でも無い限り、今まで #include <linux/kref.h> と書いてあったところが数学的に必要十分条件を満たすかどうかを検討せずに、 #include <linux/kref_api.h> と書き換えられるだけだと思う。特に driver 周りではね。

      5 年もしたら、だれかが「なんで #include <linux/xxx_api.h> って書くの?無駄じゃね?」と言い出すだろう。

      で、提案した修正でこの流儀が徹底されているかというと、徹底はされていない。例えば、include/linux/usb/composite.h は今まで通り、型定義と関数定義が仲良く header に入っている。一つのファイルを読めばどんな機能なのか一目瞭然だ。

      一つの source code tree に 2 つの流儀が混在する状況が上手くいくのだろうか?自分が関わった project の全てでガチな統一コーディングルールが有ったし、無かったらルール屋さんが現れて、ルールを作って「これに従え」と、言い出していたな。ルールはメンバーの合議で決めてるプロセスを取っていたけど、まぁ、なんだ。誰か一人の好みを押し通すだけの儀式だったな。

      今時マシンパワーで解決できること、あるいは Clang, LLVM の様に中間コード(仮想機械コード)に型情報を持たせて、リンケージ時とか object binary の高度利用で解決する方法を模索せずに、人力解決しようという流れが発生するのか...

    • by Anonymous Coward

      これヘッダファイルの依存関係を整理してビルド速度を上げようってだけで、ビルド後に出力されるプログラムコードは同等のものにすることを目指してるんだけど…

      • by Anonymous Coward

        目指してるけど、そうは行かない事が多いよねって元コメは言ってると思う。

        • by Anonymous Coward

          ところが元コメではバグに言及しているため、バグを修正することが無意識のうちに前提としてある。

        • by Anonymous Coward

          同じものを目指してると考えてたなら「旧製品を超えられない」「旧製品はバクすら仕様」なんて話が出てくるのはおかしい。

        • by Anonymous Coward

          #if defiend(A__) && defined(B__)
          #include // #define C__
          #endif

          のような文脈依存の依存関係を持っている場合は
          どういじっても既存コードへの影響が不可避ですからね。
          何もしてないのに壊れる老舗コードが出そうだなぁ。

    • by Anonymous Coward

      わかる。
      コード汚いと書き直したくなる病が出てくるけど、大体はコードではなく現実が汚い。
      なんで書き直してもやっぱり汚い。もしくは汚い部分を扱えずに旧製品を超えられない。
       
      今まで3回全面書き換えの場に立ち会ったけど、
      大失敗1、変わらず1、まあよくなった1ぐらいの結果だった。

      • by Anonymous Coward

        > 大体はコードではなく現実が汚い。
         
        それなんてみずぽ。

      • by Anonymous Coward

        いわゆるRust病ってやつだな

    • by Anonymous Coward

      実験的フォークは、何かの知見を吐き出して終えればいいと思う
      何か新コーディング スタイルを生み出すかもね

  • by Anonymous Coward on 2022年01月13日 18時56分 (#4184180)

    WindowsのカーネルをLinuxにしろと言ってた人が勝利するんですね!?

    ここに返信
    • by Anonymous Coward

      WindowsのカーネルがLinuxのようなオープンソースになったら嬉しいですね。

  • by Anonymous Coward on 2022年01月13日 21時03分 (#4184263)

    バイナリがそのままでは動かない。オープンソースだからソースコードを自分でコンパイルすれば…と思ったのですが、あちこちからライブラリを集めて来ないといけない。いざコンパイルしようとしたら集めてきたライブラリのインクルードファイルで変数の定義がかちあってコンパイルが通らない、こっちを直すとあっちがおかしくなる…本家ってどうやってバイナリ作ったの?って経験はありませんか?

    ここに返信
    • by Anonymous Coward

      そのバイナリとやらをどこから入手したのかによりますが、今どきは構築手順を示したファイル(Debian系であれば.dsc, RPM系であれば.spec)が同梱されているので、そこからコンパイルすればよいのでは。

      • 古いソフトウェアを使いたいこともあるし、パッケージになっているものばかりでもないし、ソースパッケージがないこともあるし、手順書の通りにやってもエラーになることもある。
        そういえば、こないだ wireshark をビルドしようとしたら、手順書に従ってるつもりなのに微妙にうまくいかなかったな。

        --
        svn-init() {
          svnadmin create .svnrepo
          svn checkout file://$PWD/.svnrepo .
        }
  • by Anonymous Coward on 2022年01月13日 22時58分 (#4184309)

    ソースで公開されているDriver類の互換性が失われないことを願います。
    まぁまぁ大丈夫なんですかね。。。

    ここに返信
    • by Anonymous Coward

      dkms でコンパイルしてるようなやつを全部カバーは出来ない
      というか、ちょっと前に gpio のAPI 変えたやつなんかは古いドライバはダメなんで…
      ver up にドライバが追従出来ないのは普段から良くある事です

    • by Anonymous Coward

      linuxはドライバ用APIの互換性なんて一切保証してないし、実際に結構な互換性はなくなってる。
      それの追従が面倒なんだったら本線に入れろってのが、linuxの方針。

  • by Anonymous Coward on 2022年01月14日 2時18分 (#4184369)

    CPU自体の性能向上
    ストレージの性能向上(ランダムアクセスの高速なSSD化)
    メモリ搭載量の増大により空きメモリがキャッシュに割り当てられてディスクアクセスの減少

    この3つにより、ビルド時間はどんどん高速化している

    ここに返信
    • by Anonymous Coward

      残念ながらポインタのポインタを辿るのはまだ遅いですし、文字列処理もあまり速くなっていません…
      今後SRAM 3D Stackingが登場すれば変わるかもですが、今はまだその時ではありません。

  • by Anonymous Coward on 2022年01月14日 8時47分 (#4184441)

    インライン関数自体はいいけど、ヘッダファイルに書くという仕様がよくない。

    ここに返信
typodupeerror

192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり

読み込み中...