Re: [PATCH x86_64] Live Patching Function on 2.6.11.7

[James Courtier-Dutton]

Chris Friesen wrote:
> Chris Wedgwood wrote:
> 
>> On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote:
>>
>>
>>> From our experience, sometimes patches became to dozens to hundreds
>>> at one patching, and in this case GDB based approach cause target
>>> process's availability descent.
> 
> 
>> could you perhaps explain some *real* *world* applications/systems
>> where this is necessary and why existing APIs won't work with them
>> perhaps?
> 
> 
> In the telecom space it's quite common to want to modify multiple
> running binaries with as little downtime as possible.  (Beyond a
> threshold it becomes FCC-reportable in the US, and everyone wants to
> avoid that...)
> 
> Our old proprietary OS had explicit support for replacing running binary
> code on the fly, so customers have gotten used to the ability.  Now they
> want equivalent functionality with our linux-based stuff.
> 
> We've done some proprietary stuff (ie. pre-OSDL CGL) in this area, but
> it was apparently a real pain and was quite restrictive on the
> application writers. (I was not involved with that portion of the project.)
> 
> For general application support I suspect some kernel support will be
> required.  Whether this is the way to go or whether it can be done using
> existing mechanisms, I'm not knowledgeable enough to comment.
> 
> Chris
> -

I raised a thread like this about 1 year ago. I was asking for it from
the point of view of a Telco. After some discussions on this list, I
came to agree with the posts on the list by other people that the
feature is not needed. At least certainly not needed in the Telco space.
99.999% uptime is much better acheived with the use of clustering,
rather than trying to upgrade software in a Live situation. In a
clustered environment, one offloads all the tasks from machine A and
spread them across the cluster. Once the machine A is not doing any work
at all, you can upgrade, reboot, whatever you like, and then add it back
to the cluster. This approach is much less risky than live module updates.
If the equipment is not clustered, it will at least be 2 to 1 redundent,
so you just upgrade the redundent device, manually force a fail over,
and then upgrade the other device. Again, no live update required.

I can only think of one other system that might benefit from live
updates, and that is set top boxes, so bugs can be fixed without the
user knowing. This also can be worked around by downloading the bug
fixes and only installing the bugs fixes when the user is not viewing
the TV. E.g. When the box has been placed in standby by the user.

James
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/