On 06/20/2014 06:13 PM, Karanbir Singh wrote: > On 06/20/2014 06:30 PM, Jim Perrin wrote: >> >> >> On 06/20/2014 12:15 PM, Karanbir Singh wrote: >>> hi >>> >>> since we now have a GA kernel and a zero day update kernel, does someone >>> want to have a go at creating the scripts / automation needed to deliver >>> kpatch content ? >>> >>> - KB >>> >> >> Sat through a basic presentation on this, and on the surface it seems >> reasonably easy to implement at the local level. Distro wide, it will >> become an exercise in deployment of patches, as not all things can be >> patched. There's also a reasonably insignificant (or so I'm told) >> performance penalty that will grow as more things are added to the >> kpatch list without a reboot. > > something really cool is that the kpatch process itself works quite > nicely with git, we could potentially deliver a tool that allows people > to self-implement, rather than needing to ship kpatch payload ( > otherwise, were potentially looking at a yum plugin of sorts and a rpm > based wrapper ) > > does that sound like something we could target ? Possibly, however; we haven't seen upstream deliver a kpatch, and I'm not convinced they intend to provide anything more than the functionality to make one yourself. So, we would have to extract and prepare the source of the old kernel, and the new. Diff them to generate a patch that could be distributed through git. That patch may or may not be able to be applied via kpatch. Additionally, how far back would we like to provide diffs? Do we start with the release kernel for each minor version and keep a diff? Do we only patch for the previous kernel version? I can see this feature being incredibly popular with hosters, but it would require a fair bit of planning on our part to implement properly. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77