パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Linuxカーネルの"依存関係地獄"解消目指す「Fast Kernel Headers」」記事へのコメント

  • by Anonymous Coward

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

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

    • 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

        リナックスはバザールでござ〜るからして、
        短慮な統制は邪魔にしかならないでしょうな。
        流儀が増えるだけ。無視ならまだマシ。
        LibreLinuxでも作ってそっちで挫折しとくのが一番無難かと。

※ただしPHPを除く -- あるAdmin

処理中...