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

I agree.  You don't have to get the kernel involved and it makes no 
sense to require it.

-Corey

Brian F. G. Bidulock wrote:

>Takashi,
>
>By why kernel?   It seems that there is a need to patch user-space
>applications the symbols of which are only known to the linked application
>(and perhaps the linker-loader) and completely unknown to the kernel.
>
>The use case should state whether it is the intention of this mechanism to
>patch a running kernel/kernel modules or just a running user-space process, or
>both.
>
>If it is just the user-space process, a library with simple and
>straightforward use of dlopen, a barrier for protection, and a callback for
>signalling the application of a reconfiguration event should do the trick.
>That also handles the situation of memory vs. core, because the patch could be
>applied in core and then the application signalled, resulting in a dlopen of
>the new core (and dlclose of the old).
>
>Use-cases are better if they do not presuppose some form of implementation not
>necessary to the purpose.
>
>--brian
>
>On Tue, 29 Mar 2005, Takashi Ikebe wrote:
>
>  
>
>>Ralf, I just fix some point which you are worrying, and everyone suggedted.
>>Please check and tell me your impression.
>>---------------------------------------------------
>>
>>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.
>>Distro acceptance to increase system availability while staying in sync with
>>distro releases.
>>
>>Participants/Roles
>>System administrators setup the requirements on installations.
>>On operation, application developer/administrators should provide patch 
>>module,
>>and carrier system administrators apply patch to the carrier system 
>>applications
>>which designed to use the requirement.
>>
>>Scenarios
>>On operation, system administrators apply patch with the requirement as
>>following scenario;
>>1.System administrators obtains patch modules from application 
>>developer/administrators.
>>In the case that the application is designed to use the requirement, 
>>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.
>>5.If the effect of patch is not desired, remove/deactivate the patch 
>>with provided live patch tool.
>>
>>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.
>>To improve usability, boot patch function which syncs binary image on 
>>disk to patched image on memory should be provided.
>>
>>References
>>Pannus project: http://pannus.sourceforge.net/
>>Live patching implementation:
>>http://prdownloads.sourceforge.net/pannus/pannus_en.pdf
>>
>>
>>Ralf Flaxa wrote:
>>    
>>
>>>Then it should be stated very explicitely that this feature may only
>>>be used for and by applications and that it is forbidden to patch
>>>the underlying distro with it.
>>>
>>>I am wondering why the distro then should even provide that functionality?
>>>Why doesn't the app provider take care of this himself then if it is just
>>>meant for his app?
>>>
>>>	Ralf
>>>
>>>On Mon, Mar 28, 2005 at 03:19:07PM -0700, Steven Dake wrote:
>>>
>>>      
>>>
>>>>>From the distro perspective, I can understand your serious discomfort
>>>>with supporting live patching of applications specific to the operating
>>>>system (and in the distributor's support domain).
>>>>
>>>>The live patching feature, atleast during the specs development, was
>>>>targetd for use in carrier(and other interested parties) applications
>>>>which are supported and maintained by the carriers/others.  We  never
>>>>stated in the requirements that the distribution itself must support
>>>>live patching of the entire system.  If you point out the specific
>>>>requirement that requires or implies this, then it is something that
>>>>needs adjustment in the specification..
>>>>
>>>>Perhaps wording of the intended use (for carrier applications, not for
>>>>distro upgrades) would be helpful.
>>>>
>>>>If live patching then becomes a "customer issue", it is really of no
>>>>concern to a distro whether the customer chooses to patch their own
>>>>applications or not.
>>>>
>>>>Regards
>>>>-steve
>>>>        
>>>>
>>-- 
>>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 : [email protected]
>>    
>>
>
>  
>
>>_______________________________________________
>>cgl_discussion mailing list
>>[email protected]
>>http://lists.osdl.org/mailman/listinfo/cgl_discussion
>>    
>>
>
>
>  
>