Re: LKPK (Live Kernel Patching Kit)

Chad C Giffin (
Sun, 26 Jul 1998 19:12:22 -0400 (EDT)

On Sun, 26 Jul 1998, Adam Sulmicki wrote:

:Date: Sun, 26 Jul 1998 18:24:39 -0400
:From: Adam Sulmicki <>
:To: Rik van Riel <>
:Cc: Chad C Giffin <>, Adam Sulmicki <>,
:Subject: Re: LKPK (Live Kernel Patching Kit)
:Rik van Riel writes:
:->On Sun, 26 Jul 1998, Chad C Giffin wrote:
:->> On Sat, 25 Jul 1998, Adam Sulmicki wrote:
:->> :
:->> :Date: Sat, 25 Jul 1998 19:46:34 -0400
:->> :Chad C Giffin writes:
:->> :I think you are talking about something else. I even did not try to think
:->> :about anything like this as it is _extermely_ complicated.
:->> So is going through the kernel and catching all references to variables,
:->> functions and such :-)
:->If we had linker support for this, however, we might end up
:->with a patchable kernel. To do this we'd have to store all
:->needed information in some kernel data section.
:->While this might increase the size of the kernel by a factor
:->2, it might be worth it for high-availability sites to compile
:->their kernel with CONFIG_LIVE_UPDATE...
:The problem is that all this sheme breaks when you change some
:data structure. [...]

Only in some cases. Its a matter of moving the data in an image restore
operation to the new structures.

This may break in cases where soemone has called, for example, an ioctl in
user space that returned a kernel structure (this is a *nono*) describing
a serial port. The updated kernel image may have a different structure

In my opinion the user space is not a place for a kernel structure.
I suppose changing this would be a bit of work.

Chad C Giffin

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at