Kitsune: Efficient, General-Purpose Dynamic Software Updating for C [pdf](cs.umd.edu)
cs.umd.edu
Kitsune: Efficient, General-Purpose Dynamic Software Updating for C [pdf]
http://www.cs.umd.edu/~jfoster/papers/oopsla12.pdf
3 comments
Seems like more overhead than fork & execv technique.
I've thought such DSU system for a while, and it came to me that using a simple fork/exec technique require you to save (or dump) you data somewhere, before the exec() call. If you do it with a file and your data is huge, your update is no longer "seamless". :-/
Some research (a while ago) showed me that exec() on Linux call may be parameterized in order to prevent it to cover data segment (while I am not 100% sure), but then I think it exist only for Linux and is not portable.
Some research (a while ago) showed me that exec() on Linux call may be parameterized in order to prevent it to cover data segment (while I am not 100% sure), but then I think it exist only for Linux and is not portable.
Seems like a ton of work to get this implemented into an application, and it also seems error prone (the amount of work they described to get memcached moved over, for example, sounds like it had lots of room for mistakes). And if there's anything I don't want to have room for subtle mistakes, it's live-updating a server or other critical piece of infrastructure.
The approach seems interesting, though, and it's cool to see them demonstrate that the performance impact is negligible (updates seem to apply very quickly based on their tests, too). Maybe there's a use case for this where the risk of mistakes causing failed updates/corruption is low?
The approach seems interesting, though, and it's cool to see them demonstrate that the performance impact is negligible (updates seem to apply very quickly based on their tests, too). Maybe there's a use case for this where the risk of mistakes causing failed updates/corruption is low?
Alright, I'll write a rebuttal on behalf of the authors.
First, they tested their update methodology by applying it to a long history of released versions for each piece of software.
Second, although any code involving concurrency is tricky, I thought the line counts were actually quite low:
Third, how is a broken online update any worse than a broken offline update? Is there a greater argument for data loss?
First, they tested their update methodology by applying it to a long history of released versions for each piece of software.
Second, although any code involving concurrency is tricky, I thought the line counts were actually quite low:
C LoC C delta xfgen LoC
vsftpd 12,202 113 101
redis 13,387 57 37
Tor 76,090 159 189
memcached 4,181 112 27
icecast 15,759 134 200
Third, how is a broken online update any worse than a broken offline update? Is there a greater argument for data loss?
It'd be incredibly interesting for MUD development, if anyone still did that. No need to kick everybody out for bug fixes, just post a new build. Actually, I could see it for any game with a lot of built-in state that's hard to set up between test runs: Dwarf Fortress, physics engine tuning, that sort of thing. Make it work on the PS3 and XBox 360 (and with C++!), and you've got the start of a legitimate middleware company.
Saved in my "in case I ever go back to hacking on Nethack" folder.
Saved in my "in case I ever go back to hacking on Nethack" folder.
Console vendors will probably never allow this kind of live-patching. Updates have to go through certification.
For most games I know of that do live updates, they just do it by booting up a new version of the server and 'switching' people over when they cross boundaries (most MMOs still have loading screens and server transitions, so it's not that hard). Client updates are certainly more difficult, but I'm not sure you'd ever do it - there's no way you're going to get NVIDIA or AMD to apply this technique to their video drivers, etc.
For most games I know of that do live updates, they just do it by booting up a new version of the server and 'switching' people over when they cross boundaries (most MMOs still have loading screens and server transitions, so it's not that hard). Client updates are certainly more difficult, but I'm not sure you'd ever do it - there's no way you're going to get NVIDIA or AMD to apply this technique to their video drivers, etc.
I was thinking of it as a tool for shortening dev cycle time, more than for patching: a more general, cross-platform version of Edit and Continue. My mistake; I shouldn't have started with the MUD example, I was just writing out my thoughts in real time.
Where can we find the tool suite (xfgen etc) in order to test it?
Send the authors an email.