[K42-discussion] Linux Dynamic Upgrade

[Will Schmidt]

On Tue, 2006-03-10 at 14:36 +1000, Andrew Baumann wrote:
> Hi,

> Agreed, I think a demo is the best/quickest way to show what can be done with 
> this approach. People are going to complain that the patch is ugly or has a 
> lot of hacks, but the point is that if you were going to add this kind of 
> thing properly, you would implement a lot of it at a lower level (eg. in the 
> module system instead of hacking on top).
> 
> > To me, the most likely scenario will involve a bug being discoved, code
> > getting fixed, modules being rebuilt, and then trying to load the new
> > module on top of the old one...
> 
> That's one scenario, but it is also worthwhile keeping in mind that one thing 
> you can do with this approach that you can't with hot patching (DKM, kprobes, 
> etc.) is what it was originally designed for in K42: hot-swapping. Because 
> you change the functions only for a specific instance of a module (eg. a 
> single loopback filesystem, rather than all loopback filesystems), you can do 
> interesting adaptation and optimisation by swapping to a different 
> implementation on the fly.
Hmm, this I hadnt quite thought of..  There may actually be better
response to a example of this than to a demo against loopback.   Any
thoughts on what would be a good candidate for that?

> That works for now, but one of the key things we wanted to support was updates 
> that changed the data structures maintained by a module. I think that's one 
> of the main advantages of this approach over hot patching with kprobes. I 
> guess this kind of change isn't likely for the loop device, but have you 
> thought about that at all? It means you need to not just switch the functions 
> from the old code to the new versions, but in between doing the switch you 
> need to run a state transformer function to change the data structures of the 
> module, and to do that safely you need to know that none of the old functions 
> are executing.
> 
Yup, In my mind I correlate the switcher functions with (.. I look back
at the papers to get the right terminology...) with the descriptions of
the mediator and factory objects, as that is the place where the
decision gets made to call the old or the new versions; and that would
be a likely place to put in hooks to convert the relevant data
structures.

Easiest way to show this would probally be to add a new but mostly
cosmetic data structure, and rearrange or add/remove fields per each
update.  I'd probally also need to add some versioning code at the same
time. 

At worst, I'll update my comments to include that concept for the next
round. :-) 

> That is where things get tricky, because in Linux there isn't a clean 
> mechanism to tell when threads are executing in the module's code... the only 
> approach I've seen used is walking all the kernel stacks, which feels wrong 
> to me. What we discussed before LCA is adding an entry/exit counter to all 
> the exported functions of a module. Of course, those counters would need to 
> be in the base kernel before you tried loading an update.
Yup, and what I've done here would absolutely require changes to the
base loopback code before it would work too. 

> 
> Again, it's really cool that you're trying this out in Linux. Let me know what 
> you think and if/how I can help.
> 
> Andrew
Thanks, 
-Will