Linuxカーネルを徹底探索！多層解説で理解を深めるExplorer
引用元：https://news.ycombinator.com/item?id=46066280
すごくいいね。タルムードのページの配置を思い出したよ。異邦人として、何百年、いや何千年ものコメントが同じページに収められてるのを見るのはとても興味深かったね。
https://www.reddit.com/r/interestingasfuck/comments/1acgks3/…
https://triberuth.wordpress.com/2016/09/23/my-talmud-layout-…
コードは同じように線形じゃないし、ページもそこまで意味をなさないけど、このLinux Kernel Explorerでもコメントの層っていうアイデアが響いてるね。サイドのメモがすごく気に入ったよ！
タルムードって、オリジナルのハイパーテキスト（TM）かもね（たぶん、100％確信はないけど）。
映画Piも見てみて。数字とカバラの話だけどね。 :)
https://en.wikipedia.org/wiki/Pi_(film)
HNの長年のROM専だよ！タルムード、カバラ、技術っていう僕の主な関心事に関する議論が見られてワクワクしたよ。タルムードには誤解や神秘的なイメージが多いから、ここでいくつか基本的な点を明確にしたいね。
有名な「タルムードのページ」（親コメントのリンクで議論されてる）は16世紀にキリスト教の印刷業者が作ったものなんだ。中世キリスト教の写本におけるキリスト教の主要テキストと解説の一般的なレイアウトを真似たものなんだよ[0]。
僕の意見だけど、タルムードをハイパーテキストに例えるのは特に適切じゃないんだ。タルムードは確かに聖書やミシュナーを広く引用してるし、専門用語もたくさん使うから、より良い類推は法文献（実際タルムードは法文献だからね）だね。およそ400年間（紀元100年〜500年）生きたラビたちの（架空の）”会話”や対話として表現されてるけどさ。実際、別のコメントでも言ってたけど、カバラの方が「ハイパーテキスト」のより良い例だよ。いろんなセフィロトとか他の核となる概念を指す反復的なシンボルでいっぱいだからね。
（資格として：僕は学術タルムードとカバラでMAを持ってて、いくつかの場所でこれらの主題について執筆し、学術ワークショップでも発表してるんだ。過去2年間、この仕事に関連するデジタル人文科学プロジェクトも開発してきたよ。）
参照:[0] https://seforimblog.com/2023/06/from-print-to-pixel-digital-…
[1] https://www.ezrabrand.com/p/beyond-the-mystique-correcting-c…
僕のコメントは場違いで、ルール違反かもしれないけど…これ、すごく好きだよ。Hacker Newsのユーザーがどんなトピックに対しても深くて本物の洞察を提供してくれるのが最高だね。ありがとう！
それはすごいね！！本当にありがとう！次にタルムードを学ぶためのアプリ、https://www.sefaria.org/app などについてどう思うか聞こうと思ってたんだけど、もうそのリンクで触れてくれてるんだね。読むのが楽しみだよ、ありがとう！
もちろん！Sefariaは素晴らしいよ。古典的なテキストへのアクセスを革新したね。彼らのAPIは完全なアクセスを提供してるんだ。僕が直感でコーディングしたタルムードリーダーのウェブサイトは、Sefariaからタルムード、聖書、翻訳を取得してるから、チェックしてみたら面白いかもね :)
https://chavrutAI.com/
ソースコードはこちら:
https://github.com/EzraBrand/replit-chavrutai-2
ここ数ヶ月Replitを使って直感でコーディングしてきたんだけど、すごくクールな経験だったよ。
おお、すごいね。ありがとう。
タルムードをハイパーテキストに例えるのは適切じゃないって意見、ほんと？タルムードの各ページには余白に注釈（Masoret HaShas、Ein Mishpat、Torah Or）があって、TorahやTalmud、他の法典への相互参照があるんだよ。ウェブ版ならhypertextで表現するのが自然だと思うけどな。
うん、その通りだね。「Al Hatorah」っていうサイトはまさにそれをやってるよ。例を見て：https://shas.alhatorah.org/Gemara/Berakhot/2a。でも、僕の言いたいのは、あの余白の注釈は16世紀の印刷版の産物で、Talmudの本文に元々備わってたものじゃないってことなんだ。聖書のMikraot Gedolot版も同じように注釈が豊富で、相互参照のすごいネットワークになってる。Mesorahは中世の作品で、当時の相互参照システムとしては最も精巧だったかもね。Talmudの相互参照は印刷版より前には存在しないから、そこが違うんだ。
うん、余白の注釈が16世紀の印刷版のものだって点、わかるよ。「Talmudのテキスト」をMishnaとGemaraだけと考えるなら、それで納得だね。僕はTalmudって聞くと、解説が全部載ってる印刷版を思い浮かべるんだけどさ。追記：ブログを読んだら、この点についてもうすでに言及してたんだね：https://www.ezrabrand.com/i/162112983/myth-the-talmud-is-div…
なんか見落としてるのかな。kernelのソースコードブラウジングって何年も前からオンラインであるじゃん、例えばこれ：https://elixir.bootlin.com/linux/v6.17.9/source/fs。これもそれの一つだとして、どんな追加機能があるの？bootlinのやつは検索機能もあるけど、ここでは見当たらなかったな。AI時代なんだから、コードのLLM解説とか、依存関係グラフとか、新しいkernel navigatorにはそういうのを期待してたんだけど…
どうやらページ右側に統合ガイドがあるみたいだよ。「The Kernel in The Mind」っていうMoon Hee Leeさんの本を基にしてるって書いてあるね。
それって、選んだコードに対して静的でコンテキストを考慮しないガイドなの？
君：「うわー、AIの黄金時代に突入だね！コードのLLM解説とか、AI搭載の新しいkernel依存関係ナビゲーターが待ちきれないな…」
AI時代：「まあ、せいぜい違うweb frameworkで昔ながらの機能をAIでやり直すくらいしかできないけどね。」
「API rate limit exceeded for 106.51.68.199.（でも良いニュース：認証済みリクエストはレート制限が上がるよ。詳細はドキュメントを見てね。）」
僕の場合、使ってるGitHub APIがレート制限されてるみたい。もし他の人も同じ問題に直面してたら、VPNとかCloudflare Wrapを使ってIPを変えれば直るはずだよ。追伸：もしあなたがメインの開発者なら、GitHubでログインするオプションを提供したり、キャッシュ層を使ったりすれば、新規ユーザーがもっとアクセスしやすくなると思うな。
やっほー！この問題を見つけてくれてありがとう、そして僕が使ってたすごく素朴な実装を思い出させてくれて感謝！これ、改善するね！
実装を複雑にするよりも、素朴な実装の上にキャッシュとか他のトリックを重ねる方が、良い結果になることが多いよね。
こういうツール大好き！2002年にRed Hat製の似たツールでブラジルの投票機のソースコードを見たのを覚えてるよ。重複ファイルをマッピングしてコードベースを簡素化する依頼だったんだ。Motifインターフェースのデスクトップアプリだったね。
このアイデア最高！興味深いプロジェクトのコード探索は楽しいけど、複雑なソフトウェアでは重要な部分を見つけるのが難しいよね。これはカーネルの仕組みを簡単に見るのに役立つな。
バグ見つけたよ: Chapter 2で「mm/」とかディレクトリの隣の「open」をクリックすると、「Failed to load file - Invalid file response from GitHub API - File: mm/」ってエラーが出るんだ。ディレクトリをファイルとして開こうとしてるみたいだね。
いいアイデアだし、うまく実行されてるね。Linuxカーネルへの参入障壁を下げるために、自分もいくつかプロジェクトを作ったよ。
・LinuxカーネルソースコードでUDPパケットの流れを追うアプリ: https://dmkskd.github.io/linux-kernel-network-stack-visualiz…
・MacでLinuxカーネルソースコードをいじるシンプルな方法: https://github.com/dmkskd/linux-kernel-debugging-on-mac
FlorentRevestさんのこの分野での全ての仕事に感謝！
君のUDPパケットフローツール、すごく気に入ったよ、作った人に拍手！OSでパケットがどう動くのか、ずっと知りたかったんだ。「gotoは悪魔だ」って言われるけど、そこら中にたくさんあるのは面白いね。このコードは、その「格言」が生まれるずっと前に書かれたのかもね。
それか好きだって言ってたから、Jan EngelhardtさんのNetfilterパケットフローチャートを紹介するね。
https://en.wikipedia.org/wiki/File%3ANetfilter-packet-flow.s…
ありがとう！君の興味があるなら、ここの「live」デバッガセッションのビデオを見てみて。
https://github.com/dmkskd/linux-kernel-debugging-on-mac?tab=…
もしARM64 Macを持ってるなら、簡単にセットアップできるはずだよ（今のところこのOSしかサポートしてなくてごめんね）。
カーネルの仕組みを理解する最高の入門の一つは、マイクロコントローラ上でタイマーベースのコンテキストスイッチングRTOSを実装することだったよ。少ないコードでLinuxカーネルに飛び込むための基礎を築けるからね。
あと、これね: https://elixir.bootlin.com/linux/v6.17.9/source
Elixirは長年あるけど、モバイルでもっとうまく動くよ。
Elixirは、ファイルを一つずつ見るだけじゃなくて、タグ機能もちゃんと動くから、実際のコード探索にはもっと優れてるんだ。
モバイル対応の件、指摘ありがとう！改善するね。
このExplorerは、まさに多くの人が求めてたツールだと思うよ。Linuxカーネルのソースって、ファイルが多くて構造も複雑だから読むのが大変だったけど、これは「地図」みたいに全体像を掴むのに役立つね。VFSやモジュールの繋がりも分かりやすい。たまに不具合もあるけど、カーネルのアーキテクチャを理解する第一歩として最高！開発チームに感謝だよ。
AIが書いてるかは気にしないけど、最近「プロジェクトの一般的な褒め言葉、ツールの使い道、良い点悪い点、感謝」みたいなテンプレ投稿が新しいアカウントから多いよね。AIっぽい書き方で。ボットがカルマ稼ぎしてるんじゃないかと。君がそうだとは言わないけど、似たようなスタイルだとコメントが苦戦する原因かもね。
もっとコメントを表示（1）
大丈夫だよ！今日のHacker NewsコメントがAI狩りみたいに見えるのはわかる。でも、Hacker Newsに不慣れなポジティブな人かもしれないよ。これからはAIっぽく見られないように、もっと気をつけるね！
AIかどうかは気にしないけど、最近「良いこと言って、使い道説明して、良い点と悪い点言って、感謝」みたいなテンプレ投稿が新しいアカウントで流行ってるよね。AIっぽい書き方で、ボットのカルマ稼ぎかなって。君がそうだとは言ってないけど、似たようなコメントスタイルだと、あなたの投稿が伸び悩む原因かもね。
これ、LXRを思い出すね。https://lxr.linux.no/
https://en.wikipedia.org/wiki/LXR_Cross_Referencer
Linux触り始めた頃はすごく助けられたよ。Pythonでelixirとして再実装されたみたいだね。
https://elixir.bootlin.com/
https://github.com/bootlin/elixir
これ何に使うの？masterプルできないし、grepもできない。編集もgmakeもできないじゃん。意味なくない？
これは、コードの重要な部分を指し示すナビゲーションツールだと思うな。コードを学びたいけど、どこから手をつけていいか分からない人には便利だよ。
変な質問だけど…カーネルのコードで、一番すごいとか感動する部分ってどこ？
fs/select.cかポーリングの仕組みが関係してるんじゃないかな。
わかる！VFSって読んでて楽しいんだよね。関数ポインタで汎用APIを作るっていうLinuxカーネルのパターンを知るのに最高だよ。ファイルシステムドライバーがVFSオペレーションをどう実装してるか、具体例がわかるのがいいんだ。
これの価値はインデックスじゃなくて、物語なんだよ。Linuxカーネルは30年分の歴史が詰まってて、線形に読むのは無理。Elixirはシンボル定義を教えるけど、これは「なんでこうなってるの？」って問いに答えるんだ。人間には複雑すぎるから、テキストだけじゃなく状態を可視化する考古学的なツールがもっと必要だよね。
これすごいね！著者(https://fabiomaia.eu)を見つけるのに時間かかったけど、Python版も作れないか連絡してみるよ。新しいエンジニアにcpythonリポジトリのソースコードの探し方とか、PythonかCかの判別、コード内容の理解を教えるのに役立つと思うんだ。ドキュメントが不十分な時もあるからね。
「Python版が欲しい」って？なんで自分で作らないのさ。オープンソースに素早い実装や迅速なバグ修正を期待するのって、ちょっと無茶だよ。みんなもっともっとって欲しがりすぎなんだよな。
これ、https://elixir.bootlin.com/linux と何が違うの？
Elixirには学習を助ける特別な機能はないんだよ。
うーん、全然違うものだよ。名前が似てるだけ。僕がLinuxカーネルと触れるならElixirの方が使えるかな。こっちは教科書みたいな位置づけだね。Elixirは関数定義へのリンクがあって便利だけど、これにはそれが無いんだ。
ElixirはLinuxコードの探索に良いけど、新人にはLinuxって難解だよね。
このExplorerはコード探索をすごく面白くしてくれるんだ。全てのトピックがコード参照されてて、Linux内部のインタラクティブな本って感じだよ。
右側のサイドバーのコンテンツを見てみてよ。これ、Linuxカーネルのインタラクティブなガイドブックみたいなんだ。
あのいろんなバージョンが見つからないし、なぜかElixirのリンクを開いたらファンが回りだしたよ笑
これだとナビゲーションも良くなるし、コードを読むのが全体的に速くなるね
これめちゃくちゃクールじゃん！左にある小さいアイコンがすごく気に入ったよ。クリックできたらもっといいのにね
チャプター1のこのファイル『arch/x86/kernel/entry_64.S』が開けないんだ（『Failed to load file』ってエラーが出る）。左のディレクトリツリーにも表示されてないよ。
変な話だけど、これ別のコメントでも指摘されてて、『dead（役に立たない）』にされてたんだけど、なんで？
これ、たぶん誤字だね。正しいパスは『arch/x86/entry/entry_64.S』のはずだよ
クイズの問題って、人間が作ったの？それともAI？
このガイドの最初の文が『XじゃなくてYだ。Zをする』って感じだろ？全部AIが作ったって考えても間違いないよ
最初の文の何が具体的に問題なのか、詳しく教えてくれる？『カーネルはプロセスじゃない—システムだ。ユーザープロセスにサービスを提供し、コンテキストに反応し、分離と制御を強制する。』この部分は実はMoon Hee Leeさんの『The Kernel in The Mind』に基づいているんだ。ぜひフィードバックをちょうだい
Moon Hee Leeさんの『The Kernel in The Mind』に基づいているって言うけど、これすごく面白そうなリソースだね。誰かこれの正確性とか有用性について保証してくれる人いる？オンラインで全然情報が見つからないんだ。
LinkedInの投稿シリーズか、LinkedIn投稿に添付されたPDFとしてしか公開されてないって事実が、あまり信用できないんだけど—まあ、カーネル開発者にウェブサイトの作り方を期待するのは無理なのかな？
AI生成かどうかって聞いただけで、否定しなかったね。
集中して！AI生成かどうかは人身攻撃だよ。内容を批判すべきで、どうやって作られたかは関係ない。
落ち着いて。答えは目の前にあったよ。「The Kernel in the Mind」から引用するけど、
「カーネルはプロセスじゃない。システムそのものなんだ。」
https://www.linkedin.com/pulse/kernel-mind-moon-hee-lee-miwz…
XだけどYは別のところから来たって感じだね。
記事の内容が「カーネルはプロセスじゃない、システムだ」とか、「メモリは場所じゃない、システムだ」みたいな表現ばかりで、正直読むのがツラい。これを読み続けると頭がおかしくなりそうだよ。
記事をどう修正できるか、何か建設的なフィードバックある？
もっとコメントを表示（2）
ChatGPTじゃなくて、人間が書けばいいよ。
最初の質問の一つが「カーネルとプロセスの根本的な違いは何？」なんだけど、「カーネルは特権のある特別なプロセスだ」っていう（基本的に正しい）答えを否定して、「カーネルはプロセスじゃなく、プロセスにサービスを提供するシステムそのものだ」っていうのが採用されてるのが、なんか間違ってない？カーネルは（プロセス0として）自身をプロセスとして表現してるんだよ。カーネルスレッドもスケジューリングが必要だし、明らかに特権も持ってるしね。
「カーネルは自身をプロセス（プロセス0）として表現する」ってのは、どんなモダンなOSでも本当じゃないよ。カーネルコードは単一のプロセスや限られた数のプロセスに限定されないし、カーネルモードへの移行は専用プロセスへの切り替えを必要としない。CPUの投機的実行脆弱性が出る前は、ユーザー空間プロセスの仮想アドレス空間にカーネルコードが直接マッピングされるのが一般的だった。PID 0は多くのUNIX系システムで共有されるスケジューラの単なる実装詳細で、普通のプロセスみたいに機能しないし、カーネルの大部分の動作を正確に表してるわけでもないんだ。
この記事（とあなたが返信してるコメント）はLinuxについてのものだけど、Linuxは確かに自分のスレッドをPID 0として表現してるよ。もちろん、スレッドじゃない概念もあるけど、実際のところカーネルは特別なプロセス0なんだ。
また違うよ。ほとんどのカーネルコードはPID 0として実行されないんだ。あなたが言ってるのはアイドルタスクのことで、カーネルのほんの一部にすぎない。僕もコメントを書くときはLinuxを念頭に置いてたけど、これはどんな主要な汎用OSでも基本となる動作だよ。「どんなモダンなOS」って言うとき、Linuxを除外するなんてできないでしょ。
カーネルにはアイドルタスク以外にも、いーっぱいスレッドがあるんだよね。Linuxがスレッドを実装する方法だと、PIDはゼロじゃないけど、他のプロセスのスレッドみたいにアドレス空間を共有してるよ。うちのLinuxシステムだと、ざっと265個のカーネルスレッドがあるのを見たよ。
アイドルタスク以外のカーネルスレッドでPIDが0じゃないのって、全部だろ？もっと大事なのは、kthreadsはLinuxカーネルの補助的な部分で、非同期タスクを実行する一つの方法にすぎず、カーネル全体を表すわけじゃないんだ。これじゃ、客観的に間違ってる発言を技術論で正当化しようとしてるだけだろ。カーネルは”特別なプロセスゼロ”じゃないし、プロセスでもないんだ。プロセスを動かすための仕組みをプロセスに頼れるわけないじゃん。それに、PIDを持ってる部分だってアイドルタスク以外はPID 0じゃないし。信じないなら、カーネルに聞いてみれば？/proc/0なんてないんだから。
あと第6章の「CPU状態とカーネル状態の関係」だけど、「CPUはステートレスで、カーネルが状態を管理する」ってあるのは、「均等に状態を共有する」っていうのとは違うと思うな。カーネルの方がはるかに多くの状態を管理してるだろうけど、CPUにもレジスタやキャッシュラインがあるから、ステートレスとは言えないはずだよ。
OP、シェアしてくれてありがとう！結構みんな気に入ってくれたみたいだから、フィードバックを聞いて次にどうするか考えるね！
このリアクティブガイドスタイルインターフェース、すごく好き！mdBook[1]みたいに、静的なノートと一緒にクイズや例を挿入できるプロジェクトアイデアとしてかなり良いかもね！
[1]: https://github.com/rust-lang/mdBook
@reverserdev これいいね。どんなユースケースを考えてるの？最初は、知識チェックのための質問付きでカーネルコードを巡るガイドツアーだと思ったよ。
すごくいいね、掘り下げるのが楽しみ。俺も昔（B.A.、エージェント以前）似たようなアイデアがあったんだけど、デカすぎて無理だって思ってたんだ。これってエージェントコーディングのおかげで実現できたの？
めっちゃ面白い！LLMやコーディングエージェントを使って、コードをステップ実行しながらカーネルを解説してくれるのかと思ってたけど、これはこれで良いアプリだね。
この簡単なバージョンがこんなに注目されたから、もっとダイナミックな「家庭教師」を検討中だよ！コードを「ステップ実行する」って言うとき、ソースコードのスクロールを追うような感じかな？
ファイルが何をするか説明してくれるLLMプロンプトみたいな簡単なものでも、かなり役立つと思うな。
arch/x86/kernel/entry_64.Sを開こうとすると「ファイルを読み込めませんでした」って表示されるんだけど、バグかな？
パスはarch/x86/entry/entry_64.Sだよ。
これいいね！ちょっとしたバグだけど、ファイルを変更してもファイル内の位置が0に戻らないんだ（少なくともWin11のFirefoxだと）。
Webアプリ全体がMonaco（VSCode）のモッドだと思うんだけど、すごいハックだね！
これすごくいいね。EmacsやVimみたいな他のコードベースでも同じのが見られたら面白いな。
Emacsは自己文書化されてて分かりやすいよ。何か調べるにはdescribe-*コマンドが便利だ。例えば”save-buffer”コマンドなら、describe-keybindingから入り、”describe-command save-buffer”でfiles.elのLisp定義へ。変数なら”describe-variable buffer-file-name”でC言語の領域へ。Emacsのインタラクティブな自己文書化機能は素晴らしいね、もっと広まってほしい。
なんで低評価されてるか分からないな。他の大規模オープンソースプロジェクトでもこんなサイトがあれば素晴らしいのに。
「次のトピックはスケジューラ」って言ってsched.hを指すだけのガイドって、一体どんなガイドなんだ？
学習ガイド、ありがたいね。
これ、なんとかローカルでデプロイできるかな？
