LinuxモジュールAPIに下位互換性がないのはなぜですか？
LinuxモジュールAPIに下位互換性がないのはなぜですか？Linuxカーネルを更新した後、更新されたドライバーを見つけるのに不満があります。
専用のドライバーが必要なワイヤレスアダプターを持っていますが、メーカーは約7年前にこのデバイスを製造中止にしました。コードは非常に古く、Linux 2.6.0.0用に記述されているため、最新のLinuxカーネルではコンパイルされません。私は多くのLinuxディストリビューションを使用しましたが、同じ問題がどこにでもあります。Linuxカーネルで配布されているオープンソースドライバーがありますが、動作しません。古いプロプライエタリコードを変更して最新のLinuxカーネルと互換性を持たせようとしている人もいますが、新しいLinuxカーネルがリリースされると、コードをそれと互換性を持たせるのに数か月かかります。その時間内に、別の新しいバージョンがリリースされます。このため、新しいLinuxカーネルにアップグレードすることはできません。ディストリビューションをアップグレードできないこともあります。
回答
Greg Kroah-Hartmanは、このトピックについて次のように書いています。 https://www.kernel.org/doc/html/v4.10/process/stable-api-nonsense.html
Cコードのコンパイルに関するいくつかの技術的な詳細に加えて、彼は決定を下すいくつかの基本的なソフトウェアエンジニアリングの問題を引き出します。
Linuxカーネルは常に進行中の作業です。これは多くの理由で発生します。
- 新しい要件が発生します。人々は自分のソフトウェアにもっと多くのことをしたいと思っています。それが私たちのほとんどがアップグレードする理由です。私たちは最新かつ最高の機能を求めています。これらは、既存のソフトウェアのやり直しが必要になる場合があります。
- 修正が必要なバグが見つかりました。バグはデザイン自体にあり、大幅な手直しなしでは修正できない場合があります。
- ソフトウェアの世界では新しいアイデアやイディオムが生まれ、人々は物事を行うためのはるかに簡単/エレガント/効率的な方法を見つけます。
これはほとんどのソフトウェアに当てはまり、保守されていないソフトウェアはゆっくりと痛みを伴う死を迎えます。あなたが求めているのは、なぜその古いメンテナンスされていないコードがまだ機能しないのですか？
古いインターフェースが維持されないのはなぜですか？
下位互換性を確保するには、古い（多くの場合「壊れた」安全でない）インターフェイスを維持する必要があります。もちろん、これを行うことは理論的には可能ですが、かなりのコストがかかります。
グレッグクローハートマンは書いています
Linuxが安定したソースインターフェイスを維持することを保証する必要がある場合、新しいインターフェイスが作成され、古い壊れたインターフェイスを長期間維持する必要があり、[開発者]の余分な作業につながります。すべてのLinux [開発者]は自分の時間に作業を行うため、プログラマーに無料で追加の作業を無料で依頼することはできません。
Linuxはオープンソースですが、それを維持するための開発者の時間はまだ限られています。したがって、人的資源は依然として「コスト」の観点から議論することができます。開発者は、時間をどのように使うかを選択する必要があります。
- 古い/壊れた/遅い/安全でないインターフェースを維持するために多くの時間を費やしてください。これは、最初のインスタンスでインターフェイスを作成するのにかかった時間の2倍から3倍になる場合があります。
- 古いインターフェースを遠ざけて、他のソフトウェア保守者が[自分の仕事をして]自分のソフトウェアを保守することを期待してください。
結局のところ、インターフェースのビニングは（カーネル開発者にとって）本当に費用効果が高いです。開発者が何ヶ月も何年も費やさない理由を知りたい場合は、新しいWi-Fiアダプターに10ドルを支払う必要がありません...それが理由です。これはカーネル開発者にとって時間/費用効果が高く、必ずしもあなたやメーカーにとって費用効果が高いとは限らないことを忘れないでください。
私はLinuxカーネルにいくつかの（非常にマイナーな）パッチを提供しましたが、私は自分自身をカーネル開発者とは見なしていません。しかし、これが私が知っていることです：
カーネルバージョン2.6.0.0用に作成されたドライバーは、カーネルバージョン2.6.39で発生したBig Kernel Lock（BKL）の廃止よりも前のものです。
BKLは、Linuxがまだシングルプロセッサ（シングルコア、シングルスレッド）のOSであったときに作成されました。SMPサポートが追加されるとすぐに、開発者はBKLがいずれかの時点で大きなボトルネックになることを認識しましたが、システム全体にコア/スレッドが数個しかない限り、ある程度許容できました。しかし、最初はスーパーコンピューターでLinuxを使用している人々にとって深刻な問題となったため、BKLを必要とするすべてのものを、よりきめ細かいロックメカニズムに、または可能な場合は常にロックレス方式に置き換える作業が始まりました。
サーバーはもちろん、通常のデスクトップやハイパワーラップトップに2桁のコア数がある最新のコンピューターでは、2.6.0の下位互換性のあるカーネルモジュールAPIもBKLを実装する必要があります。
レガシーモジュールが「BKLを取得したい」と言った場合、カーネルの残りの部分には、モジュールがそれをどのように処理するかがわからないため、下位互換性メカニズムは、BKLを置き換えたすべてのロックを取得する必要があります。すべての可能性をカバーするためだけに。それは大きなパフォーマンスヒットになるでしょう。また、新しいロックレスメソッドでは、レガシーロックをチェックする必要があります。これは、そもそもロックレスであるという点を打ち負かします。したがって、下位互換性メカニズムが存在するだけで、レガシーモジュールが実際にロードされていなくても、システムのパフォーマンスが低下します。
最近では、Spectre / Meltdownセキュリティパッチにより、カーネル/ユーザースペースの境界を超えたときに何が必要かが大幅に変更されました。Spectre / Meltdownの修正が実装される前にコンパイルされたモジュールは、Spectre / Meltdown後のカーネルでは信頼できない可能性があります。
ちょうど2週間前、自動化によってセキュリティ更新プログラムが適用されたときに手動で電源を入れ直す必要がある古いサーバーのトラブルシューティングを行っていました。これは以前に数回発生しており、再現可能でした。megasrSpectre / Meltdownパッチの前から、自動更新に含まれていなかった非常に古いバージョンの専用ストレージドライバーが含まれていることがわかりました。ドライバを現在のバージョンに更新した後、問題は解決しました。ちなみに、これはプレーンなRHEL6.10システム上にありました。
また、Spectre / Meltdown後のカーネルで独自のSpectre / Meltdown前のハードウェア監視ドライバーをロードするとサーバーがクラッシュするのを見ました。この経験に基づいて、Spectre / Meltdownの修正は分水界イベントとして扱う必要があると完全に確信しています。カーネルとモジュールはすべて修正前または修正後のバージョンである必要があります。ミキシングとマッチングは、オンコールのシステム管理者に対する悲しみと深夜のウェイクアップコールにのみつながります。
そして、スペクターはCPU設計レベルの問題だったので、それは「与え続ける贈り物」です。弱点を悪用する新しい方法を見つける人もいれば、カーネル開発者は悪用をブロックする方法を見つける必要があります。
これらは、2.6.0.0互換のレガシーカーネルモジュールAPIが解決する必要のある大きな問題の2つにすぎません。他にもたくさんあると思います。
そして、より哲学的な側面があります。考えてみてください。Linuxを可能にするものは何ですか？
その大部分はオープンハードウェア仕様です。ハードウェア仕様が公開されていれば、誰でも参加できます。オペレーティングシステムのソースコードは公開されているので、誰もが貢献でき、誰もが利益を得ることができます。また、ドライバーコードがオープンソースの場合、ハードウェアプログラミング仕様を企業秘密として保持することはできません。
Linuxカーネル開発者は、オープンソースモデルを信じる傾向があります。彼らは彼らの設計と開発の選択肢を作っ参加するハードウェアの製造元のための好ましい方法は、ドライバはオープンソースであること、それは（とメインカーネルのソース配布にマージした後、取得している理由ですだけにして）あなたはよそれを維持することで、カーネル開発者コミュニティ全体の利益を得ることができます。
これは、ハードウェアの設計者や製造業者にこれを可能にするインセンティブを提供します。秘密にしておきたいものがある場合は、ASICにカプセル化するか、必要に応じて署名付きファームウェアにカプセル化するようにしてください。（後者を行う場合は、ファームウェアパッケージを再配布する許可を他の人に付与してください。）
ただし、カーネルはオープンソースであるため、カーネル開発者は、他の人が独自のドライバーを個別に保守することを完全に防ぐことはできません。しかし、彼らにも彼らを気にする動機はありません。
実際、カーネルのデバッグでプロプライエタリバイナリドライバによって引き起こされる余分な手間は、カーネル開発者がプロプライエタリドライバの開発を気にしないインセンティブです。「彼らは私の仕事をより困難にします。
したがって、カーネル開発者は通常、グループ/コミュニティとして最も有利なことを行います。モジュールAPIの変更が含まれている場合は、そうしてください。サードパーティのドライバーは、方程式にさえ入りません。