Linux –ユーザースペースを決して壊さないLinuxカーネルポリシーがあるのはなぜですか？

Linuxカーネルメーリングリストのエチケットの文脈でこの問題について考え始めました。世界で最も有名で、間違いなく最も成功し、重要な自由ソフトウェアプロジェクトとして、Linuxカーネルは多くの報道を受けています。そして、プロジェクトの創設者でありリーダーであるLinus Torvaldsは、明らかにここで紹介する必要はありません。

Linusは、LKMLの炎で物議を醸すことがあります。これらの炎は、彼自身の承認により、ユーザースペースの破壊に関係していることがよくあります。それが私の質問につながります。

ユーザースペースを壊すことがなぜそんなに悪いことなのかについて、歴史的な見方をすることができますか？私が理解しているように、ユーザースペースを壊すにはアプリケーションレベルでの修正が必要ですが、カーネルコードを改善するのであれば、これは悪いことですか？

私が理解しているように、Linusのポリシーは、ユーザースペースを壊さないことが、コードの品質を含む他のすべてよりも優先されるというものです。なぜこれがそれほど重要なのですか、そしてそのようなポリシーの長所と短所は何ですか？

（このようなポリシーには明らかにいくつかの短所があり、一貫して適用されています。Linusは、まさにこのトピックに関してLKMLのトップ副官と「意見の相違」がある場合があるためです。私が知る限り、彼は常に問題に取り組んでいます。）

承認された回答：

その理由は歴史的なものではなく、実際的なものです。 Linuxカーネル上で実行される多くの多くのプログラムがあります。カーネルインターフェースがそれらのプログラムを壊した場合、誰もがそれらのプログラムをアップグレードする必要があります。

現在、ほとんどのプログラムは実際にはカーネルインターフェイスに直接依存しておらず（システムコール）、C標準ライブラリのインターフェイス（システムコールのCラッパー）にのみ依存しています。ああ、でもどの標準ライブラリ？ Glibc？ uClibC？ Dietlibc？バイオニック？ Musl？など

ただし、OS固有のサービスを実装し、標準ライブラリによって公開されていないカーネルインターフェイスに依存するプログラムも多数あります。（Linuxでは、これらの多くは/procを通じて提供されます。および/sys 。）

そして、静的にコンパイルされたバイナリがあります。カーネルのアップグレードでこれらのいずれかが壊れた場合、唯一の解決策はそれらを再コンパイルすることです。ソースがある場合：Linuxはプロプライエタリソフトウェアもサポートしています。

ソースが利用できる場合でも、すべてを収集するのは面倒な場合があります。特に、ハードウェアのバグを修正するためにカーネルをアップグレードする場合。多くの場合、ハードウェアサポートが必要なため、システムの他の部分から独立してカーネルをアップグレードします。リーナス・トーバルズの言葉で：

ユーザープログラムを壊すことは単に受け入れられません。（…）人々は何年もの間古いバイナリを使用していることを私たちは知っています、そして新しいリリースを作ることはあなたがそれを捨てることができるという意味ではありません。あなたは私たちを信頼することができます。

彼はまた、これを強力なルールにする理由の1つは、新しいカーネルを動作させるために別のプログラムをアップグレードする必要があるだけでなく、さらに別のプログラムをアップグレードする必要がある依存関係地獄を回避することであると説明しています。、すべてがすべての特定のバージョンに依存しているためです。

やや明確に定義された一方向の依存関係があっても大丈夫です。悲しいですが、避けられないこともあります。（…）問題は、双方向の依存関係を持つことです。ユーザースペースのHALコードが新しいカーネルに依存している場合、それは問題ありませんが、ユーザーはそれが「今週のカーネル」ではなく、「過去数か月のカーネル」になることを望んでいると思います。
>
しかし、双方向の依存関係がある場合は、失敗します。つまり、ロックステップでアップグレードする必要があり、それは受け入れられないということです。ユーザーにとっては恐ろしいことですが、さらに重要なのは、「バグが発生した」とは言えず、二等分線などで絞り込むことができないため、開発者にとっては恐ろしいことです。

ユーザースペースでは、これらの相互依存関係は通常、異なるライブラリバージョンを維持することで解決されます。ただし、実行できるカーネルは1つだけなので、カーネルを使用して実行したいすべてのことをサポートする必要があります。