Linuxファイルシステム階層にREADMEがないのはなぜですか？

Linuxファイルシステム階層（FHS）には、多くの重要なディレクトリが含まれています。たとえば/sys/class/input、PS / 2キーボード設定で遊んでいるところを発見しました。

しかし、これらの重要なディレクトリはすべて別の場所に文書化されているためman /sys/class/input、特定の時点で何が起こるかを説明するようには機能しません。

README階層にファイルを配置して、人々が特定のレベルで何が行われているのかを学習し、内容を操作しやすくしませんか？デバイスが独自READMEのをマウントすることさえできれば、それは本当に素晴らしいことです。

あなたの例を使用するには：/sys/「実際の」ファイルは含まれていませんが、完全にカーネルによって提供されています。すべてのREADMEをカーネルの一部にしますか？あなたはおそらくしません。

ドキュメントはにあり/usr/share/docます。ハードディスク上の通常のファイルが含まれています。いくつかについてのドキュメント/sysと/procしているカーネルソース、である/usr/src/linux/Documentation（カーネルソースをインストールして、あなたの現在のカーネルのシンボリックリンクを作った場合）。

UnixとLinuxには、manページ（およびGNUシステムではinfoファイル ...）を使って文書化するという10年前の伝統があるためです。man（1）、man（7）、man-pages（7）を参照してください。ところで、manコマンドとページはオプションです（すべてのUnixシステムにインストールするわけではありません）。

ファイルシステム階層はhier（7）で説明されています。

これは、https：//wiki.linuxfoundation.org/lsb/fhsで入手可能なFilesystem Hierachy Standardによって定義されています。

いくつかのファイルシステム、特に/proc/（proc（5）を/sys/参照）と（sysfs（5）を参照）は、カーネルコードによって提供される疑似ファイルシステムです。そのようなREADME-sを生成する追加のコードでカーネルを肥大化させたくない（これは、大多数のユーザーには役に立たない）。カーネルの構成ファイルでさえ、ほとんどのカーネル構成では無効になっていることが多いため、オプションでしか利用できません。また、多くのLinuxシステムは組み込みシステム（スマートフォン、スマートアプライアンスまたはIoTデバイス、RaspberryPIなど）であり、リソースが浪費されるのを防ぐのに十分なほど恐ろしいものです。/proc/config.gz

特に/sys/、sysadminsと低レベルのユーティリティを作成する開発者にとって最も有用であり、両方とも適切にドキュメントを見つけることができるはずです。

READMEファイルを階層に配置して、何が起こっているのかを人々が簡単に学習できるようにしてください

そのようなが本当に必要な場合はREADME、それらを提供する独自のロード可能なカーネルモジュールを作成するか、それらを提供するようにいくつかのunionfsをセットアップします。努力する価値はないと思います（そして、unionfsをオンに/sysすると、システム全体が遅くなる可能性があります）。

カーネルコードは使用されなくても、RAMを消費します（ページアウトされることはなく、仮想メモリではなく物理メモリに常駐します）。したがって、肥大化を避けることは理にかなっています。