[cgl_discussion] Re: [cgl_specs] Use case - Live patching

Timothy D. Witham wookie at osdl.org
Mon Mar 28 08:33:24 PST 2005

On Mon, 2005-03-28 at 09:05 -0600, Corey Minyard wrote:
> Why do you think it is evil?  It is standard practice in most large 
> telecom systems as it improves availability.
    Maybe it would be better to word it as "it can improve
But it really is a hold over from the single large expensive CPU design

    If you don't exercise absolute top down control you get to a
were there isn't a correlation between what is on the disk for a reboot
and what is in memory being executed.   While a phone company
might be able to control their switch with rather infrequent updates
in the general usage this can cause real issues. 

 In fact from my support of phone company days I remember a 
couple of issues where switches where bounced because of a 
major environmental issue and when they came back up they
were missing features and patches.  They were in such a sorry
state that they had to be reloaded in order to function correctly.   

> -Corey
> Ralf Flaxa wrote:
> >Speaking for SUSE/Novell I can at least say that live patching is evil
> >and would never be considered supported. How shall you guarantee support
> >or certification with such a mechanism in place?
> >
> >	Ralf
> >
> >On Mon, Mar 28, 2005 at 11:14:50AM +0900, 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
> >>
> >>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.
> >>
> >>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
> >>
> >>
> >>-- 
> >>Takashi Ikebe
> >>NTT Network Service Systems Laboratories
> >>9-11, Midori-Cho 3-Chome Musashino-Shi,
> >>Tokyo 180-8585 Japan
> >>Tel : +81 422 59 4246, Fax : +81 422 60 4012
> >>e-mail : ikebe.takashi at lab.ntt.co.jp
> >>    
> >>
Timothy D. Witham - Chief Technology Officer - wookie at osdl.org
Open Source Development Lab Inc - A non-profit corporation
12725 SW Millikan Way - Suite 400 - Beaverton OR, 97005
(503)-906-1911  (office)    (503)-702-2871   (cell)
(503)-626-2436  (fax)

More information about the cgl_discussion mailing list