Linuxではカーネルに対してパッチを当てる際、OSの再起動、つまりダウンタイムが発生することは基本的に避けられない。このパッチ当てとそれに伴うダウンタイムの発生は運用管理者にとっては実に頭が痛い問題なのだが、これを回避するためのソリューションとして、Oracle、Red Hat、SUSEの3社はそれぞれ独自にライブパッチ機能の開発を続けてきた。
なかでも有名なのはOracleの「Ksplice」だろう。Oracleは2011年7月、ゼロダウンタイムでのカーネルパッチ適用を実現する技術をもつKsplice社を買収した。Kspliceのコード自体はオープンソース（GPLv2）として公開されているものの、買収時までサポートはKsplice社が行っていた。この時点でKsplice社のサポートを受けていた企業は約700社、サポート対象機は10万台を超えていたが、当然ながら各社が使用するLinuxディストリビューションはさまざまであった。
Oracleは買収後、「KspliceのサポートはOracle Linuxのみで行う」という方針を打ち出し、買収前のKsplice社では行っていたRed Hat Enterprise Linuxでのサポートも中止している。現在も一部の旧Kspliceユーザを除き、Oralce LinuxユーザでなければKspliceのサポートを受けることはできない。
これに対し、Red HatとSUSEはそれぞれ独自のライブパッチ機能として、「kpatch」（Red Hat、2014年2月）および「kGraft」（SUSE、2014年1月）の開発をスタートさせている。そしてこの両者は当時から互いにコラボレーションすることを画策していたようだ。
SUSE Labsにおいてカーネルチームのリーダを務めるJiri Kosina氏は2月9日（中央ヨーロッパ時間）、Linuxカーネル開発者のメーリングリスト「lkml.org」に「Live patching for 3.20」というタイトルで投稿、SUSEとRed Hatが共同でライブパッチ機能のカーネルへの実装を開始したことを明らかにし、「livepatching」とした最初のバージョンをGitに置いている。
これまでkpatchとkGraftでは、モジュールの生成方法はほとんど一緒だったが、カーネルへのパッチの当て方が異なっていた。差分のトレースにはどちらもカーネル由来のftraceを使用するが、stop_machine()を使って古い関数から新しい関数へと書き換えるkpatchに対し、kGraftはstop_machineを使わず、RCU（Read Copy Update）に似た同期システムで古い関数を保持しつつ、スレッドごとに新しい関数への書き換えをダイナミックに行っていく。もし両者を統合するなら一貫性を保つことが重要なポイントになる。すなわち古い関数と新しい関数が混在するような事態は避けなくてはならない。
Kosina氏は「今回のバージョンでは、APIなどライブパッチに必要な基本となる関数書き換え機能は含めているが、きわめてシンプルで最小限の構成。サポートアーキテクチャも現時点ではx86のみだが、PowerPCとS/390については準備中」としている。投稿のタイトルに"for 3.20"とあるように、可能な限り次のカーネルリリースであるLinux 3.20に間に合わせたい意向だと思われる。カーネルレベルでのライブパッチ機能の実装が実現すれば、LinuxはOSとしてこれまでになく大きな飛躍を遂げることになる。プロジェクトの推移に今後とも要注目だ。
