Dynamic software updating in C
kitsune-dsu.com
Dynamic software updating in C
1–10 of 20 posts
Re: Dynamic software updating in C
#2Seems interesting! It would be nice to have a diff between the base version and patch-ready version of the various software (eg, redis). It's hard to quickly understand what the integration of this into an large, existing piece of software would be.
That being said, I haven't read the paper so it may be clear as day there.
Re: Dynamic software updating in C
#3Very cool, this is one of the reasons I love Erlang and Java. Hot-patching is so simple.
Re: Dynamic software updating in C
#4Very cool, this is one of the reasons I love Erlang and Java. Hot-patching is so simple.
Honest question; How can you even do this (replace the running binary/java code without closing file descriptors, etc) in plain java/on the jvm? [ Without resorting to tricks where there is some trampoline code that actually does the connection handling that never gets updated. I realize that's kind-of what the authors of the linked paper are doing too, but it's certainly possible to do this "the old fashioned way" without such hacks in native code on linux]
Re: Dynamic software updating in C
#5Seems interesting! It would be nice to have a diff between the base version and patch-ready version of the various software (eg, redis). It's hard to quickly understand what the integration of this into an large, existing piece of software would be. That being said, I haven't read the paper so it may be clear as day there.
The paper describes the main changes that you have to make to make your program updatable and is the best resource.
You can find all the modified programs (redis, etc) here: https://github.com/kitsune-dsu
Re: Dynamic software updating in C
#6Very cool, this is one of the reasons I love Erlang and Java. Hot-patching is so simple.
Honest question; How can you even do this (replace the running binary/java code without closing file descriptors, etc) in plain java/on the jvm? [ Without resorting to tricks where there is some trampoline code that actually does the connection handling that never gets updated. I realize that's kind-of what the authors of the linked paper are doing too, but it's certainly possible to do this "the old fashioned way" w…
To answer my own question here, but without being a java expert, so talking out of ignorance probably. This paper [1] argues there are only two methods to do this on the stock JVM. One is putting in some trampoline code, the other one is patching the JVM. So it looks like the stock JVM doesn't actually support restarting the program while keeping the old heap and FDs etc around.
Re: Dynamic software updating in C
#7This was work done as part of my phd thesis. You can take the code and samples that are here https://github.com/kitsune-dsu and play with them. However, I wouldn't consider what has been released ready for production use. The papers were the main product of this research and are your best resource if you're interested: http://www.cs.umd.edu/~hayden/papers/kitsune-draft.pdf
I moved on (graduated!) from the project in 2012 and the code that has been released is pretty much where I left it at that time. An undergrad collaborator was doing neat work on updating Tor, so that code continued to evolve a bit after I left.
I think there may still be folks at UMD working in some ways with Kitsune, but I'm not up on the details.
Re: Dynamic software updating in C
#8This was work done as part of my phd thesis. You can take the code and samples that are here https://github.com/kitsune-dsu and play with them. However, I wouldn't consider what has been released ready for production use. The papers were the main product of this research and are your best resource if you're interested: http://www.cs.umd.edu/~hayden/papers/kitsune-draft.pdf I moved on (graduated!) from the project in…
Thanks for the very interesting article. One thing I didn't find very clear from the paper was the rationale of using a framework/kitsune/all that wrapper code vs just implementing the feature natively. In other words, what is the upside of using kitsune to make e.g. redis live-upgradable vs just implementing it in redis proper [I believe that e.g. redis already uses a fork model for writing the data to disk/getting a snapshot of the data]? Is it much simpler when I am using kitsune? Do I really not have to reason about what happens when the binary upgrades? Or is this mostly useful for retro-fitting the feature to software that wasn't designed with the usecase in mind?
Re: Dynamic software updating in C
#9This was work done as part of my phd thesis. You can take the code and samples that are here https://github.com/kitsune-dsu and play with them. However, I wouldn't consider what has been released ready for production use. The papers were the main product of this research and are your best resource if you're interested: http://www.cs.umd.edu/~hayden/papers/kitsune-draft.pdf I moved on (graduated!) from the project in…
I was thinking using this to update our graphics software, but then I realized I need to backup GPU states (textures, for example) and recover them before and after the update.
lots of the servers are now using gpus for deep learning, may be adding gpu support to the framework is a good feature.
Re: Dynamic software updating in C
#10This was work done as part of my phd thesis. You can take the code and samples that are here https://github.com/kitsune-dsu and play with them. However, I wouldn't consider what has been released ready for production use. The papers were the main product of this research and are your best resource if you're interested: http://www.cs.umd.edu/~hayden/papers/kitsune-draft.pdf I moved on (graduated!) from the project in…
Thanks for the very interesting article. One thing I didn't find very clear from the paper was the rationale of using a framework/kitsune/all that wrapper code vs just implementing the feature natively. In other words, what is the upside of using kitsune to make e.g. redis live-upgradable vs just implementing it in redis proper [I believe that e.g. redis already uses a fork model for writing the data to disk/getting…
Kitsune provides useful abstractions for modifying your program for runtime updating and tools for automating state transformation between versions of your program.
It would be entirely reasonable to implement DSU all within an app's own codebase, particularly until there's a production-ready library/tool-set. The downside would be that you'd probably end up re-implementing a lot of what Kitsune provides.
For our purposes (evaluating Kitsune-style updating on a variety of server programs), it made sense that we'd want to have a common toolset that we applied to all of the programs.