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

Brian F. G. Bidulock bidulock at openss7.org
Tue Mar 29 22:03:43 PST 2005


How did live-patching specialized applications turn into live-patching
glibc?  Or, the kernel for that matter?

Also, your fear is that the live-patch context is the target process,
yet your goal was to include it in the kernel and also have the ability
to patch the kernel.  Is not then the kernel (patch context) patching
the kernel (target process)?

I am glad that you have removed these implementation specifics, however,
I think that you still need to scope the use case to user, kernel or


On Wed, 30 Mar 2005, Takashi Ikebe wrote:

> The point what we focus is lowering difficulty of application development.
> Yes you can make it all in user-mode, but we think it makes coding rule 
> more difficult, If implement it as library base(means live-patch context 
> is target process itself).
> Or makes performance worse if implement is as gdb base(means live-patch 
> context is control process).
> In our case, we take emphasis on "easy-programing" and "performance", so 
> we choose kernel base. It's trade-off.
> Kernel live patching? Not mentioned in this use-case,(because there is 
> no working open source implementation yet.) however final destination is 
> there.
> Anyway, "kernel" is implementation method, so I changed description and 
> outcome.
> ---------------------------------------------------
> Description
> OSDL CGL specifies that carrier grade Linux shall provide a mechanism and
> framework by which a custom application can be built so that it can be
> upgraded by replacing symbols in its live process.
> Dynamic replacement of symbols allows a process to access upgraded functions
> or values without requiring a process restart, and in many circumstances can
> lead to improved process availability and uptime.
> Desired Outcome
> Mainline acceptance.
> Distro acceptance to increase system availability while staying in
> sync with distro releases.
> Corey Minyard wrote:
> > 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:
> >>

Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
bidulock at openss7.org    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

More information about the cgl_discussion mailing list