Kitsune: Efficient, General-Purpose Dynamic Software Updating for C [pdf] | Hacker News Reader

Kitsune: Efficient, General-Purpose Dynamic Software Updating for C [pdf]

cs.umd.edu

23 pointsgeorgeorwell9 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.

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?

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.

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.

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.

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:

               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

where C LoC is the original program length, C delta is the changes to the program, and xfgen LoC is extra specification stuff they had to write.

Third, how is a broken online update any worse than a broken offline update? Is there a greater argument for data loss?

Where can we find the tool suite (xfgen etc) in order to test it?

Send the authors an email.

Reply on news.ycombinator.com