On Tue, 20 Sep 2005 18:07:17 EDT, John Richard Moser said: > These bugfixes don't typically change the exported binary interface of > the existing functions being corrected, and so it would be feasible to > halt all processors and execute an atomic codepath to switch the symbols > in the running kernel to point to the replacement functions from the old > ones. If big functions are split up into smaller ones, as long as the > interface is the same for all existing functions, it shouldn't matter as > well. I believe telco switch software has been doing patch-on-the-fly for quite a long time. It's a royal pain in the butt, especially if you have any dynamic 'struct foo_ops' lurking. And you can't just plop the code in either - let's say the fix includes "add a state bit to the 'struct foo_ctl' to track XYZ". Now you need to think about the fact that there's likely kmalloc'ed struct foo_ctl's already out there that don't know about this bit. Hilarity ensues....
Attachment:
pgpNPAqccywM2.pgp
Description: PGP signature
- Follow-Ups:
- Re: Hot-patching
- From: John Richard Moser <[email protected]>
- Re: Hot-patching
- References:
- Hot-patching
- From: John Richard Moser <[email protected]>
- Hot-patching
- Prev by Date: Re: Hot-patching
- Next by Date: Fw: Problems with modular sound
- Previous by thread: Re: Hot-patching
- Next by thread: Re: Hot-patching
- Index(es):
