カーネルモジュールをロードする際の実行中カーネルに対する整合性チェックの仕組みには、vermagic と modversions の 2 種類があります。 太古の昔は・・・ 古いカーネルでは、モジュールをコンパイルする際に使ったカーネルソースのバージョン・ストリング(include/linux/version.h)を見て、ロード可能なカーネルを決定していたような記憶がかすかに・・・。これは、安全性と柔軟性の両面において『帯に短し、たすきに長し』でした。 ・安全にロードできるカーネルを厳密にチェックするという意味では、不十分です。(同じバージョン名でも、カーネルの Config オプションが異なる可能性などを排除できない。) ・複数バージョンのカーネルにロードできるモジュールを作れないので、もちろん柔軟性に欠けています。 その後、安全サイドをより強固にサポートする vermagic と、柔軟
マクロの定義 SPECファイルの冒頭にパッケージのバージョンなど頻繁に使用されるものをマクロとして定義しておくと後々の修正が楽になります。 %define macro literal ようにするとパッケージ作成時に%{macro}と書かれた部分をliteralに置換して処理します。 「標準で定義されているマクロ」も参照して下さい。 以下にパッケージ情報の記述例を示します。(#を記述すると#から行末までがコメントとして扱われます。) # 基本情報 Summary: hoge is a harehare horehore Summary(ja): hoge は harehare な horehore です。 Name: hoge Version: 1.1 Release: 1%{?_dist_release} License: GPL2 Group: Applications/Internet
カーネルのバージョンが上がる度にカーネルモジュールもビルドしなきゃいけない,というのはめんどくさい。 しかも。 バイナリパッケージでカーネルモジュールをインストールしているとする。 このカーネルモジュールがシステム動作の上で必須だとすると,新しいカーネル(本体)がリリースされても,それに対応するバージョンのカーネルモジュールがリリースされない限り新しいカーネルにアップデートすることができない。 これは不便。そして危険。 なので,RHEL 5 から KMP (Kernel Module Package) という新しいカーネルモジュールのパッケージング方式がでてきた。 たとえば,centosplus のバイナリパッケージ(IIJ さんのミラー)で XFS のカーネルモジュールのパッケージを見ると, kmod-xfs-0.4-1.2.6.18_92.1.1.el5.centos.plus.i68
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く