:Date: Sat, 25 Jul 1998 15:52:14 -0400
:From: Adam Sulmicki <adam@cfar.UMD.EDU>
:To: linux-kernel@vger.rutgers.edu
:Cc: adam@cfar.UMD.EDU
:Subject: LKPK (Live Kernel Patching Kit)
:
:
:Hello,
:
: I'm currently writing an LKPK. The idea is that you can
: "patch" your running kernel against an kernel bug and you
: can continue run your mission critical server without
: having to reboot machine.
:
*cough* *sputter* *hack*
I just starting designing such a thing last week. I made the mistake of
talking about it on IRC and now suddenly I see this? [1]
I think you are going about it all wrong; I shall therefore describe what
I have designed insofar. May all present who are intrested please give me
their feedback so I can properly adjust my design. I will most likely
-not- being coding it as I have 10 gazillion [2] projects on the go
already.
The Idea:
-------------------------------------------------------------------------
Linux Kernel Live Kernel Updating System Revision 0.2
by Chad C Giffin Wednesday July 15th, 1998
PURPOSE:
To provide a means by which one may upgrade his kernel image and,
at the same time, not interrupt services, vm, or running processes by
allowing the administrator to boot a new kernel image overtop the
existing image.
IMPLIMENTATION:
- write time to cmos
- stop, as much as possible, all sources of interrupts
by temporarily pausing devices, tcp streams, ect.
- a flag for each driver should be set indicating
that a kernel switch over is in progress. Much
like a spinlock on device drivers to prevent
processing of any further data and to flush current
processing.
- clear interrupt enable flag
- clear all fs cache (sync) and drop buffers
- flush sockets and remove all skbs
- save map of each processes virtual memory, state as
well as image to swap while indexing these entries in
a predetermined location in RAM. (Save State Map)
- save state of all sockets and file descriptiors to
swap and index this entry in aforementioned location
in RAM. (Save State Map)
- load into high memory new kernel image
- drop to "bootstrap" code in lower (<1Mb) RAM
- uncompress new kernel image to starting point
- initialize new image with a flag & structure
indicating the function (kernel image switchover)
and location of the Save State Map.
----- NEW KERNEL ----
- initialize whatever is required
- load previous settings for devices and initialize
devices not supporting kernel switch-over
- re-instate open sockets and files
- setup vm maps for swapped processes
- read cmos clock
- enable interrupts
PROS:
Basically allows one to boot into a known stable kernel without
interrupting much of anything. (Possibly enjoy keeping the uptime
counter, heh).
CONS:
Some processes/devices may not enjoy the momentary pause in resources
for whatever reasons (time sensitve things) or perhaps clients external to
the box.
Requires some moderate changes to drivers so that we can re-start them
after loading their configurations as though they already initialized.
-------------------------------------------------------------------------
This is a simple draft! Don't go crazy on me.
I would like to hear what everyone has to say about it as I find it very
intresting and would love to tackle the job [when I find the time to do
so].
A modularized approach at function replacement could also be implimented
such as Adam is suggesting.
Sincerely,
Chad C Giffin
[1] I have heard absolutely 0 mention of any idea remotely
resembling this before and have to ponder connections
between your post and my babble on IRC.
[2] slight exageration, albeit, however not by much. By biggest
project on the go is a software emulation of an Intel 80386 [3]
[3] Actually emulation of an Intel 80[345]86 motherboard with
VLB/ISA bus system with cards (IO/Video) coded into
insertable (runtime insertable) ELF modules. Should prove
to become invaluable for kernel debugging and protected
mode assembly work.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html