今回はRHELのマイナーバージョン間での互換性維持で重要な位置を占める「kABI」を紹介します。linuxカーネルのソースコードを変更して完全にビルドしなおすという方法もありますが、linuxではカーネルモジュールとよばれる仕組みでその機能を実現しています。典型的にはデバイスドライバがカーネルモジュールとして実装されていて、ハードウェアが接続されたことを検出して対応するカーネルモジュールを読み込みます。このような仕組みで、現在動作中のシステムでは必要ない膨大なハードウェア用のドライバを扱わずにすむようになっています。Mapperなどの使う場合にはカーネルに必要だが使わない場合には全然使わないというカーネル機能の多くがカーネルモジュールとして実装されています。ここまでは「カーネルの一部機能を必要に応じて読むようにしてリソースを節約する」という話でしたが、同じカーネルモジュールの仕組みを「カーネルにない機能をあとから追加する」ためにも利用できます。この仕組みには多くの用途がありますが典型的な例としては以下のようなものがあります。独自のファイルシステムを実装するlinuxカーネルに含まれるものとは別バージョンのデバイスドライバを提供するバックアップ用にストレージへの書き込みで変更されたブロックを記録するマルウェア対策ソフトでlinuxの権限管理を拡張して、あやしい動きを拒否したり監査ログを出力したりするこれらは、linuxカーネル内にもともと存在しないソフトウェアをlinuxカーネルの一部として動作させるものです。linuxカーネルの互換性linuxカーネルの開発コミュニティは「ユーザランド」と呼ばれる、システムコールやアプリケーションソフトウェアの互換性については非常に厳しく互換性を維持するポリシーで開発をおこなっています。過去バージョンのlinuxカーネルむけに作成されたアプリケーションソフトウェアが動作しなくなることは滅多にありませんし、非互換が報告されれば対応するべき問題として扱われます。カーネルの内部については非常にダイナミックな変更が行われます。このポリシーで注意するべき点はカーネル内部で動作するカーネルモジュールに対しては互換性が維持されないということです。過去のlinuxカーネルで動作していたカーネルモジュールが将来のlinuxカーネルで動作することは一般に保証されておらず、また動作しなくなっても特にバグ扱いになったりもしません。アンチウイルスソフトウェアを作成したい、バックアップソフトウェアを作成したいという場合には問題になりえます。4.16版......」のようにどんどん変更をしていく必要があるということです。3.10.0」といっても無条件で同じカーネルモジュールを利用できるとは限りません。よばれる仕組みを提供しています。Interfaceの略で、カーネルモジュールが利用するインタフェースのことです。whitelistとは下のようなプロセスです。whitelistに登録されたシンボルのインタフェース(型)が過去バージョンと同じであることを自動テストで確認するこの仕組みを使っても、100%問題が起きないとは言えません。インタフェースが同一であっても、関連する修正が行われればふるまいは完全に同一ではなくなり、そのふるまいの変化で非互換が発生する場合があります。インタフェースが変更されればそもそもカーネルモジュールを読み込むこともできなくなります。非互換性が発生する原因を大幅に減らせるため、有用な仕組みです。whitelistsに掲載されたkABIについては互換性を維持しています。whitelistsに登録されたインタフェースのふるまいが変わり、非互換が発生した場合にはバグとして取り扱われます。whitelistに含まれていないシンボルを検出することができます。whitelistに含まれていないシンボルを利用している場合には、サポート窓口までお報せください。オブジェクト管理に関して皆さんこんにちは、ソリューションアーキテクトの岡野です。ソリューションアーキテクトの小島です。HatでOpenShiftのサポートをしているid:nekopです。各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。