[cgl_discussion] Re: [cgl_specs] Use case - Live patching
cminyard at mvista.com
Tue Mar 29 11:44:42 PST 2005
I agree. You don't have to get the kernel involved and it makes no
sense to require it.
Brian F. G. Bidulock wrote:
>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
>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.
>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.
>>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
>>Mainline kernel acceptance.
>>Distro acceptance to increase system availability while staying in sync with
>>System administrators setup the requirements on installations.
>>On operation, application developer/administrators should provide patch
>>and carrier system administrators apply patch to the carrier system
>>which designed to use the requirement.
>>On operation, system administrators apply patch with the requirement as
>>1.System administrators obtains patch modules from application
>>In the case that the application is designed to use the requirement,
>>make patch file from diff file or new version's source code.
>>2.System administrators load patch to the process with provided live
>>3.System administrators activate patch to the process with provided live
>>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.
>>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
>>- 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
>>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.
>>Pannus project: http://pannus.sourceforge.net/
>>Live patching implementation:
>>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?
>>>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.
>>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
>>cgl_discussion mailing list
>>cgl_discussion at lists.osdl.org
More information about the cgl_discussion