Hi folks, Ksplice is very interesting and I've spoken with a few people about it before. I met the (local to Cambridge, MA) ksplice guys several times and recently talked to them about the kinds of things they're doing right now. Uptrack is a nice showcase of the technology for sure. More comments below... On Tue, 2009-06-30 at 04:49 +0200, Kevin Kofler wrote: > Michael Cronenworth wrote: > > From looking at their website, it sounds like this software can take > > you from say kernel 2.6.27 to 2.6.29 without rebooting? Sounds like > > black magic. I'm intrigued. It relies upon using the existing module loading code to stop the kernel at a given moment in time (which might have to be attempted several times before succeeding in applying the ksplice patch, if the code paths being updated are currently being exercised) and inserts careful jumps to new code replacing existing functions wholesale with new ones. > It actually can't and this is why it isn't very useful within Fedora, as we > get big updates, not just minimal security patches. It would be useful for stable security updates in an enterprise distribution, and it is useful to some people in community distributions - but there's a lot of effort involved and this is where the ksplice guys have invested time in their infrastructure which we would have to entirely duplicate (and engineers too) to do this in Fedora. > KSplice can't handle that kind of updates. Actually, it technically can. > It can only handle small patches which don't change any data structures. That's a load of <removed>. I'm not sure where you get this idea from - perhaps because it's not obvious how they might achieve structural updates and so you assume it cannot be done - but actually, they can handle most kinds of update. They achieve this with shadow data structure tracking and manage the ABI differences - see the paper - and implement pre/post code hooks for things that cannot be done without a human kernel engineer. So you can also apply initcall-time fixes by implementing a custom pre-hook to perform what would happen at boot. But anyway, yes, it gets complex. And I've no doubt that for the Ubuntu kernel they're doing this for at the moment they have some of the kernel engineers they have on staff actively writing pre/post hooks. > So the official Fedora kernel updates will never be > suitable to be distributed through KSplice. That's not technically true either. It's just not practical. We would need a much larger team of people and all of the infrastructure tools developed by the ksplice guys. And it's indeterminate what the end goal would be from that - most people are happy to reboot occasionally, and those who are not can already pay Ksplice, Inc. to make updates for them. I'm not sure this is something Fedora can practically offer. Also - for those kernel folks reading. Don't discount ksplice because it sounds ugly. Tim and Waseem really do get it, and they know what they're doing - and they're actively engaging with upstream to get the bits that could be in the mainline kernel in there (ksplice doesn't require any existing kernel modifications because it also injects its own code during the ksplice patch application as part of the wrapper module). I suggest if you're interested in "add this random code patch here" type of kernel development/testing that you add ksplice to the toolbox. Jon. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
