LinuxモジュールAPIが以前のバージョンと互換性がないのはなぜですか？ Linuxカーネルを更新した後、更新されたドライバが見つからず、悩んでいました。
独自のドライバーを必要とするワイヤレスアダプターがあり、メーカーは約7年前にデバイスを停止しました。コードは非常に古く、Linux 2.6.0.0用に書かれているため、最新のLinuxカーネルにコンパイルされません。私は多くのLinuxディストリビューションを試してみましたが、同じ問題がどこにでも現れます。 Linuxカーネルと共に配布されるオープンソースドライバがありますが、動作しません。いくつかの人々は古い排他的なコードを最新のLinuxカーネルと互換性があるように修正しようとしますが、新しいLinuxカーネルがリリースされるとコードが互換性を持たせるのに数ヶ月かかります。この間、別の新しいバージョンがリリースされました。したがって、新しいLinuxカーネルにアップグレードすることはできません。時にはディストリビューションをアップグレードすることもできません。
ベストアンサー1
私はLinuxカーネルにいくつかの（非常にマイナーな）パッチを提供しましたが、自分自身をカーネル開発者とは思いません。しかし、私が知っているのは次のとおりです。
カーネルバージョン2.6.0.0用に作成されたドライバが日付より古い。BKL（大きなカーネルロック）の削除これはカーネルバージョン2.6.39で発生します。
BKLは、Linuxがシングルプロセッサ（シングルコア、シングルスレッド）オペレーティングシステムであるときに作成されました。 SMPのサポートが追加されると、開発者はBKLがある時点で大きなボトルネックになることを認識しましたが、システムにコア/スレッドの総数がいくつかある限り、これはやや許容できました。しかし、これはスーパーコンピュータでLinuxを使用している人にとって初めて実際の問題になったため、BKLが必要とするすべてをよりきめ細かなロックメカニズムまたは可能であればロックフリーの方法で置き換えることが始まりました。
サーバーはもちろん、平均デスクトップおよび高性能ノートブックで2桁のコア数を持つことができる最新のコンピュータでは、2.6.0より前のバージョンと互換性のあるカーネルモジュールAPIにもBKL実装が必要です。
レガシーモジュールが「BKLを取得したい」と言うと、カーネルの残りの部分はそのモジュールがこのモジュールで何をするのか全くわかりません。可能性。これは膨大な性能低下をもたらすだろう。新しいロックレスアプローチでは、レガシーロックも確認する必要があり、これは当初ロックなしの目的を無効にします。したがって、レガシーモジュールが実際にロードされていなくても、以前のバージョンとの互換性メカニズムがあると、システムのパフォーマンスが低下する可能性があります。
最近、Spectre / Meltdownセキュリティパッチは、カーネル/ユーザースペースの境界を超えたときに発生する必要がある作業を大幅に変更しました。 Spectre / Meltdown修正が実装される前にコンパイルされたモジュールは、Spectre / Meltdown以降のカーネルでは安定しない可能性があります。
わずか2週間前、私はセキュリティ更新プログラムが自動的に適用されている間に手動で電源を入れ直す必要がある古いサーバーの問題を解決していました。これは以前も何度も起こり、繰り返すことができます。megasr自動アップデートに含まれていないSpectre / Meltdownパッチより前の非常に古い独自のストレージドライババージョンがあることがわかりました。ドライバを最新バージョンにアップデートした後、問題がなくなりました。ちなみに、これは在庫RHEL 6.10システムにあります。
また、独自のPre-Spectre / Meltdownハードウェア監視ドライバをロードするSpectre / Meltdownポストカーネルを使用すると、サーバーがクラッシュすることがわかりました。この経験に基づいて、私はSpectre / Meltdown修正を小数点イベントとして扱う必要があると全く信じています。カーネルとモジュールはどちらもプレフィックスであるか、どちらもポストフィックスでなければならず、混合と一致は問題を引き起こすだけです。 -duty sysadmins 悲しみと真夜中の目覚め。
幽霊だからCPU設計レベルの問題、これは「引き続き提供される贈り物」です。誰かが弱点を活用する新しい方法を見つけ、カーネル開発者はこれらの脆弱性をブロックする方法を見つけなければなりません。
これは、2.6.0.0準拠のレガシーカーネルモジュールAPIに対処する必要がある2つの大きな問題です。私は他の多くの人がいると確信しています。
もっと哲学的な側面もある。考えてみてください。何がLinuxを可能にするか。
その大部分はオープンハードウェア仕様。ハードウェア仕様が公開されると、誰でも参加できます。オペレーティングシステムのソースコードが公開されているため、誰でも貢献することができ、誰にとっても利益になります。ドライバコードがオープンソースの場合、ハードウェアプログラミング仕様を営業秘密に保つことはできません。
Linuxカーネル開発者はオープンソースモデルを信じる傾向があります。そのため、ハードウェアメーカーが好む参加方法はドライバをオープンソースにし、それをデフォルトのカーネルソースディストリビューションにマージしてから（そしてその時) カーネル開発者コミュニティ全体のメンテナンス特典を享受できます。
これは、ハードウェア設計者と製造業者がこれを可能にするインセンティブを提供します。秘密にしたいことがある場合は、ASICにカプセル化するか、必要に応じて署名付きファームウェアにカプセル化してください。 （後者を選択した場合は、他の人にファームウェアパッケージを再配布する権限を付与してください。）
しかし、カーネルはオープンソースなので、カーネル開発者はそれを正確に知ることはできません。防ぐ他のものは、独自のドライバを別々に維持する必要はありません。しかし、彼らはまた、彼らに興味を持っている動機はありません。
実際、カーネル開発者は、カーネルのデバッグ時に排他的なバイナリドライバによって引き起こされる追加の面倒な問題に動機付けられます。いいえ独自のドライバ開発の懸念：「彼らは私の仕事をより難しくします。なぜ彼らの仕事をより簡単にするために特別な措置を講じるべきですか？」
したがって、カーネル開発者は一般的にユーザーにとって最高の仕事をします。それらグループ/コミュニティへ。これにいくつかのモジュールAPIの変更が含まれている場合は、そうします。サードパーティのドライバも関係ありません。