古いインターフェイスが維持されないのはなぜですか?

古いインターフェイスが維持されないのはなぜですか?

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の変更が含まれている場合は、そうします。サードパーティのドライバも関係ありません。

答え2

Greg Kroah-Hartmanはこのトピックについて次のように書きました。https://www.kernel.org/doc/html/v4.10/process/stable-api-nonsense.html

Cコードのコンパイルに関するいくつかの技術的詳細に加えて、意思決定のためのいくつかの基本的なソフトウェアエンジニアリングの問題について説明します。


Linuxカーネルはいつも進行中の作業です。これはさまざまな理由で発生する可能性があります。

  • 新しい要件が続きました。人々はソフトウェアがより多くの機能を実行したいと思っています。これが私たちのほとんどがアップグレードし、最も優れた最新の機能を望む理由です。既存のソフトウェアを再作業する必要があるかもしれません。
  • 修正が必要なバグを見つけてください。時には、かなりのリワークがないと修正できないデザイン自体に関連するバグも見つかる場合があります。
  • ソフトウェアの世界では、新しいアイデアと習慣が現れ、人々は仕事をするよりシンプルでエレガントで効率的な方法を見つけます。

これはほとんどのソフトウェアに当てはまります。保守されていないソフトウェアは、遅くて痛い死を迎えます。。古い、メンテナンスされていないコードがなぜ動作しないのかを尋ねていますか?

古いインターフェイスが維持されないのはなぜですか?

以前のバージョンとの互換性を確保するには、古い(しばしば「損傷」して安全でない)インターフェイスを維持する必要があります。もちろん、実際に重要なことでなければ、理論的には可能です。コスト

グレッグ・クロハートマン(Greg Crowhartman)が書いた。

Linuxが安定したソースインタフェースを維持する必要がある場合は、新しいインタフェースが作成され、古くて破損したインタフェースは時間の経過とともに維持する必要があるため、[開発者]に追加の作業が発生します。すべてのLinux [開発者]は自分の時間に自分の仕事を実行するので、プログラマーに追加の作業を無料で要求することは不可能です。

Linuxがオープンソースであるにもかかわらず、開発者はそれを維持する時間がまだ限られています。したがって、従業員は依然として「費用」の観点から議論することができます。開発者は時間をどのように過ごすかを選択する必要があります。

  • 古い、破損、遅く、安全でないインターフェイスを維持するために多くの時間を費やしてください。時には、最初のインスタンスでインターフェイスを作成するのにかかる時間の2〜3倍になることがあります。
  • 既存のインターフェイスを捨てて、他のソフトウェアマネージャを期待してください。【仕事を上手にして】あなた自身のソフトウェアを維持してください。

全体的に、ビニングインターフェイスは本当に費用対効果が高いです。(カーネル開発者向け)。開発者が他の人を救うのに何ヶ月も、何年も費やさない理由が気になる場合$10 支払新しいWi-Fiアダプタの場合...これがまさにその理由です。これはカーネル開発者にとって時間/費用効率が高いですが、あなたや製造業者にとっては必ずしも費用対効果が高いわけではありません。

関連情報