システムの残りをそのままにしてLinuxカーネルを更新する

私はOpenBSDユーザーです。ではOpenBSDのよくある質問、それは言います：

OpenBSDは完全なシステムであり、同期を保つことを目的としています。カーネルとユーティリティを別々にアップグレードすることはできません。

システムをアップグレードすると、一度にアップグレードできます。カーネルとベースシステムが置き換えられます。次に、サードパーティのパッケージを更新します。sourceからコンパイルする場合は、カーネルを再コンパイルして起動します。次に、ベースシステムを再構築してから、インストールしたパッケージを再構築します。すべてを最後に再構築してから数週間/月以上経過している場合、最初にスナップショットをインストールしてそこから再構築します（最新のCVSブランチをフォローしている場合）。

同期していないカーネル、ベースシステム、サードパーティのパッケージがあると、潜在的な問題の原因になり、公式メーリングリストからの真剣なヘルプを得ることができなくなります。

これで大丈夫です。実際、これがOpenBSDを使用する理由の1つです。これにより、システムが一貫したユニットになり、精神的な概要を簡単に形成できます。

Linux上ではどんな感じですか？私が知っているほとんどのLinuxには、BSDと同じ意味での「ベースシステム」はありませんが、ディストリビューションプロバイダーによってアセンブルされたパッケージのコレクションがあります。その後、ローカル管理者によって追加のソフトウェアが追加され、最初から存在していたものと後で追加されたものとの境界がせいぜいぼやけているようになります。

Linux（一般的に）は、ユーザー空間への強力なカーネル結合を持っていませんか？ カーネルは、私が知る限り、他のソフトウェアパッケージと同様に更新されますが、これが可能であることを少し混乱させます。さらに、カスタムカーネル（OpenBSDでは推奨されていません）をコンパイルし、ブートメニューにさまざまなカーネルバージョンがリストされていることもあります。

Linuxシステムのさまざまなサブシステムが互いに独立して更新されている場合でも、だれが、またはどのようなサブシステムが互いに協力できることを保証しますか？

私が尋ねている理由は、このサイトの別のユーザーが、自分のLinuxシステムのカーネルを新しいバージョンに置き換えることができるかどうかを尋ねたからです。物事のOpenBSD側から来ると、はい、これがシステムを壊さないことが保証されるとは言えませんでした。

上記の「Linux」は、「Linuxディストリビューション」、カーネル+ユーティリティの省略形として使用しています。

Linus Torvaldsは、ユーザー空間の回帰を引き起こすカーネルの変更に対して非常に強い意見を持っています（詳細については、「Linuxカーネル：ユーザー空間の破壊」の質問を参照してください）。

ユーザースペースとカーネル間のインターフェースは、システムコールによって提供されます。新しいカーネルでは、より多くのシステムコールを使用できます。また、既存のアプリケーションを破壊しない場合、既存のカーネルを変更することもできます。システムコールインターフェイスにフラグパラメータがある場合、新しいカーネルは多くの場合、新しいビットフラグで新しい機能を公開します。このようにして、カーネルは古いアプリケーションとの後方互換性を維持します。

ユーザー空間を壊さずに既存のインターフェイスを変更できない場合、拡張機能を提供するシステムコールが追加されました。これがdup、umountシステムコールの3つのバージョンと2つのバージョンがある理由です。

安定したユーザースペースを持つというポリシーが、カーネルの更新がユーザースペースアプリケーションで問題を引き起こすことはほとんどなく、カーネルのアップグレード後に一般に問題を期待しない理由です。

ただし、カーネルインターフェイスやその他の実装の詳細については、同じAPIの安定性は保証されません。SYSFS（上/sys）とprocsfsは（上/proc/）は、低レベルのアプリケーションによって使用される等ランタイム構成、ハードウェア、ネットワーク、プロセス上のカーネルの実装の詳細を公開します。正当な理由がある場合、これらのインターフェイスはカーネルバージョン間で互換性のない方法で変更される可能性があります。変更は可能な限り非互換性を最小限にしようとしますが、アプリケーションが問題を引き起こす可能性が最も低い方法でインターフェイスを使用する方法に関するルールがあります。低レベルでないアプリケーションがこれらのインターフェースを使用するべきではないため、影響も制限されます。

@PeterCordesは、 procfsまたは sysfsの変更がディストリビューションの初期化スクリプトで使用されるアプリケーションを破壊する場合、問題が発生する可能性があることを指摘しました。

これは、ディストリビューションがカーネルを更新する方法（長期サポートまたはメインライン）にある程度依存し、ディストリビューションは通常、更新されたツールを同時に出荷するため、問題は比較的まれです。

@StephenKittは、アップグレードされたユーザー空間には新しいバージョンのカーネルが必要になる可能性があると付け加えました。その場合、システムは古いカーネルで起動できない可能性があります。

LinuxカーネルとLinuxディストリビューションのユーザー空間は、歴史的にGNUプロジェクトによって開発されたユーザーツールが支配的でしたが、疎結合されています。これは一部は設計によるものであり、一部は必然的なものです。

カーネルとベースユーザースペースが一緒に設計および保守されるBSDとは異なり、Linuxカーネルとそのユーザースペースは異なる人々によって開発され、保守されています。ですから、たとえコミュニティがそれを望んでいたとしても、それらをしっかりと結びつけるのは難しいでしょう。

また、@ sebasthは、Linuxカーネルプロジェクトの主要なポリシーは、ユーザー空間を壊してはならないという素晴らしい点を指摘しています。もちろん、これは疎結合を強制する別の要因です。

ただし、ある程度の結合がまだあります。十分に古いLinuxカーネルは、最新のディストリビューションでは機能しません。

私の理解では、Linux はカーネルであり、その他はすべて補助的です。通常、カーネル自体ではなくライブラリに関連付けられているため、（多くの）インストールされたパッケージとは無関係にカーネルをアップグレードできます。通常、カーネルバージョンとハードウェアドライバー（GPUドライバーなど）の間のこのような結合のみが表示されます。 一部のソフトウェアはカーネルの特定のバージョンとのみ互換性がありますが、それらのプログラムの個々のドキュメントで指定する必要があります。

システムにインストールされている2つのカーネルパッケージスイート（現在使用されているパッケージと以前にインストールされたパッケージ）が一般的です。アップグレードする場合、新しいバージョンが適切に機能することを確認した後、最も古いバージョンを削除しても、安全な既知のフォールバックがあります。たとえば、Red Hat（およびそのいとこ）は、package-cleanup --oldkernels --count 2これを自動的に行う必要があります。

ここでのすべての適切な議論に加えて、役立ついくつかのポイントを追加することができます。

カーネルチームのポリシーは既に知っています。Linuxディストリビューションとして、カーネルソースコードを可能な限り純粋に保つよう努めています。つまり、脆弱性が発生した場合、またはパッチが必要な場合は、カーネルチームに通知し、パッチのサポートを試みますが、最終的にはカーネルチームが最終決定を下します。

一部のディストリビューションは他のディストリビューションよりも追加のパッチを追加しますが、アイデアはアップストリームの開発者からのパッチをそのまま維持することです。明らかに、特別なカーネル構成、特に仮想化とサードパーティのドライバーを必要とするプログラムがいくつかあり、通常、両方とも特定のカーネルバージョンまたは少なくとも古すぎるバージョンで動作するために使用されます...理由は最新のカーネル機能を使用するため、古いカーネルで実行しようとすると、正しく機能しない場合があります。

念頭に置いておく必要があるもう1つの要素は、すべてのLinuxディストリビューションにメンテナーチームがあり、すべてのソフトウェアがシステムと互換性があることを保証する人々です。そのため、ほとんどすべてのディストリビューションには安定バージョンと不安定バージョンがあります。開発者は「不安定な」ソフトウェアを使用し、すべてがテストされると、通常のユーザーがパッケージをアップグレードできるようになった後にのみ安定としてマークします。 。

だから、誰が、コミュニティ、そして一般的なアプローチであるべきか、私たちはシステムを壊さないで、一緒に働くソフトウェアを必要とします、それがFilesystem Hierarchy Standardのようないくつかの標準に従うことを試みる理由です。