カーネルを順番にアップグレードしていくための差分が，パッチとして配布さ
れています．例えば，今バージョン 1.1.45 を使用していて，どこかに
`patch46.gz' があることに気づきました．これはそのパッチをあて
ることで，バージョン 1.1.46 にアップグレードできることを意味します．ま
ずソースツリーをバックアップしたほうがよいかもしれません
(`make clean' して，
`cd /usr/src; tar zcvf old-tree linux' すれば圧縮された
tar ファイルが作成できます)．
例を続けます．/usr/src に `patch46.gz' があるとします．
/usr/src に cd して `zcat patch46.gz | patch -p0'
を実行してください(パッチが圧縮されていない場合は
`patch -p0 < patch46' を実行してください)．画面がすごい勢
いで(遅いシステムの場合はぱらぱらと)流れて行き，個々のパッチ当てに成功
したかどうかが表示されます．通常この表示は読むには速すぎるので，うまく
行ったのかどうかわかりません．そんなときは -s フラグをつける
といいでしょう．こうすると patch コマンドはエラー以外のメッセー
ジは表示しなくなります(「おれのコンピュータは何か書き換えているぜ!」っ
て実感はないですが，こっちの方がお好みかもしれません)．うまく行かなかっ
た部分を見つけるには /usr/src/linux へ cd し，
.rej という拡張子のついたファイルを探してください．特定のバー
ジョンの patch コマンド(恐らく低機能なファイルシステム上でコ
ンパイルされた古いバージョンの patch)は拡張子 #
をパッチ当てできなかったファイルにつけます．.rej を探すには
`find' コマンドが使えます．
find . -name '*.rej' -print
とすると，カレントおよびその下のサブディレクトリに存在する，拡張子
.rej を持つファイルが全て標準出力に表示されます．
すべてうまく行ったら，3 章と 4 章で説明したように `make clean',
`make config', `make dep' を行います．
patch コマンドにはかなり多くのオプションがあります．上述の通
り，-s はエラー以外のメッセージを出さなくなります．カーネルソー
スを /usr/src/linux 以外に置いているなら(そのディレクトリで)
patch -p1 とすることでうまくパッチを当てられます．他のオプショ
ンについては，man コマンドで詳しい説明を読むことができます．
(注意: この節は主に大昔のカーネルについてです)
以前，patch が `config.in' というファイルを書き換え
てしまい，これが正しくないという問題がよく起こりました．これは，あなた
がご自分の環境に合わせてオプションを変更していたためです．この問題は
［新しいリリースでは］修正してありますが，古いリリースでは起こることが
あるかもしれません．修正するには，config.in.rej ファイルを読
んで，どこが元のパッチのままになっているか見ます．変更された部分は行の
はじめに `+' と `-' で印がつけてあります．印で囲まれ
た部分を見て，それらに `y' と答えたか `n' と答えたか
思い出してください．それから config.in を編集し，必要なら
`y' を 'n' へ，'n' を 'y' に変更し
てください．
patch -p0 < config.in.rej
として成功したら(パッチ当てに失敗しなかったら)，カーネルの設定とコンパ
イルを続けてください．config.in.rej ファイルはそのまま残りま
すが，消去してしまって構いません．
まだ何か問題があるのなら，壊れたパッチを当ててしまったのかもしれません．
patch が `previously applied patch detected: Assume -R?'
と言ってきたら，現在より古いバージョンのパッチを当てようとしているので
しょう．この問いに 'y' と答えると patch はソースのバー
ジョンを下げようと試みますが，恐らく失敗します．その結果，カーネルソー
ス全体を改めて持ってこなくてはならなくなります(まず，これは悪い手では
ありませんでした)．
パッチを当てたものを元に戻すには，元のパッチで `patch -R' します．
パッチ当てに失敗してしまったときの最良の手段は，新たにまっさらのソース
ツリー(例えば linux-x.y.z.tar.gz ファイル)を持ってきて最初か
らやりなおすことです．
いくつかパッチを当てると，.orig ファイルがたまってきます．例
えば，私が 1.1.48 で最後に .orig を消去した 1.1.51 のソースツリー
では，.orig を消すことで 500 kBのディスクスペースが空きました．
find . -name '*.orig' -exec rm -f {} ';'
とすれば .orig を全て始末できます．パッチ当てに失敗したファイ
ルに .rej ではなく # を使用するバージョンの
patch では，.orig のかわりにチルド(tilde)を
使用してください．
.orig ファイルを消去するためのより良い方法もありますが，これ
は GNU xargs のバージョンによります：
find . -name '*.orig' | xargs rm
あるいは「極めて確実だが，もう少しおしゃべりな」方法として：
find . -name '*.orig' -print0 | xargs --null rm --
があります．
Linus が配布している以外にもパッチがあります(私はこれを「非標準」と呼 ぶことにします)．このようなパッチを当てると Linus のパッチが当たらなく て非標準のパッチを取り除くはめになったり，ソースやパッチを修正しなけれ ばいけなかったり，新しいソースをインストールしなおしたり，あるいはこれ らを組み合せて対応しなくてはならなくなるかもしれません．これは大変スト レスのたまることですから，(悪い結果になりそうな)ソースの変更を望まない なら Linus のパッチを当てる前に非標準パッチを戻すか，さもなくば新しい ソースをインストールしなおしましょう．それから非標準のパッチがまだうま く当たるかどうか確認します．うまく行かなければ，古いカーネルを使い続け るか，うまく行くようにソースやパッチと戯れるか，新しいバージョンのパッ チが出てくるのを待って(もしかすると泣きついたりして)ください．
標準の配布に含まれていないパッチはどれくらい一般的なんでしょうか? 標 準でないパッチのうわさを聞くこともあるでしょう．私はカーソルが点滅する ことをどうしても許せないので，仮想コンソールでカーソルが点滅しないパッ チを当てていました(このパッチは(少なくとも以前は)新しいカーネルのリリー スに合わせて頻繁にアップデートされていました)．しかし，ローダブルモジュール として開発されているほとんどの新しいドライバについては，``非標準'' の パッチが出現する頻度はとても低くなってきています．