Re: [cgl_tech_board] Use case - Live patching
Mary Edie Meredith <[email protected]> Mon, 28 Mar 2005 09:11:12 -0800
| Newsgroups | gmane.linux.kernel.carrier-grade |
|---|---|
| Organization | OSDL |
| Message-ID | <1112029872.3169.1454.camel@localhost> |
A few suggestions. See below. On Sun, 2005-03-27 at 18:14, Takashi Ikebe wrote: > The following is a use case for a Live patching. This > addresses AVL10.0 Live patching on CGL Specification 3.0. > Please feel free to comment / suggestion. > > Takashi. > ----------------------------------------------------------------------------------------------- > Description > OSDL CGL specifies that carrier grade Linux shall provide the mechanism > for dynamically replacing the symbols of a running process without > restarting. Dynamic replacement of symbols allows a process to access > patched functions or values without restarting and can improve process > availability. > > Desired Outcome > Mainline kernel acceptance or distro acceptance I suggest that CGL use this entry to state the desired outcome of the steps being described in the use case. In this case (I'll take a stab here) it is "to increase system availability while staying in sync with distro releases." If you want to describe how you expect the solution to reach the end-customer, I suggest you call that "Target Acceptance" > > Participants/Roles > System administrators setup the requirements on installations. On > operation, system administrators apply patch with the requirement. > > Scenarios > On operation, system administrators apply patch with the requirement as > following scenario; > 1.System administrators make patch file from diff file or new version's > source code. > 2.System administrators load patch to the process with provided live > patch tool. > 3.System administrators activate patch to the process with provided live > patch tool. > 4.Confirm that the patch is correctly applied or not. I suggest you add something for backing out a patch that fails. In light of the other suggestions, maybe you need a tool that tracks what you have in memory with any given distro release. The result might be a comprehensive patch to that release so you can recover from reboot. That is yet another scenerio, perhaps. > > Implementation Notes > The requirement need to have following functions; > - The function which loads the patch file to target process's memory area. > - The function which overwrites the branch operation code to the patch, > on the entry point of target process's functions which wants to fix by > patch. > - The function which restores overwritten branch code. > - The function which unload the patch files. > Through above functions, the requirement realize on-line patch to target > process. > The requirement need to provide on-line patch even if the process is > multi-thread model process, or environment is SMP, and stop time of > target process should not over 100 milliseconds. > > References > Pannus project: http://pannus.sourceforge.net/ > Live patching implementation: > http://prdownloads.sourceforge.net/pannus/pannus_en.pdf -- Mary Edie Meredith [email protected] 503-906-1942 Open Source Development Labs _______________________________________________ cgl_discussion mailing list [email protected] http://lists.osdl.org/mailman/listinfo/cgl_discussion