[CentOS-devel] ksplice and CentOS

Thu Jul 21 22:09:59 UTC 2011
Marian Marinov <mm at yuhu.biz>

On Friday 22 July 2011 00:25:29 Tru Huynh wrote:
> On Thu, Jul 21, 2011 at 04:10:10PM -0500, Jerry Amundson wrote:
> > On Thu, Jul 21, 2011 at 4:04 PM, Karanbir Singh <mail-lists at karan.org> 
wrote:
> > > On 07/21/2011 09:56 PM, Jerry Amundson wrote:
> > >> So you mean, developing from the ground up, something "ksplice-like"?
> > >> The "ksplice" I see out there is closed source, and was purchased by
> > >> Oracle today, for what it's worth... :-(
> > > 
> > > ksplice has always been GPL friendly, or I've been lead to believe by
> > > the guys who wrote it originally. I have a git clone from earlier this
> > > year and it clearly indicates the code as being GPLv2.
> > > 
> > > Happy to publish it.
> > 
> > Please do! :-)
> > The download links in this WikiPedia article are already zapped as well.
> > http://en.wikipedia.org/wiki/Ksplice
> 
> http://dev.centos.org/~tru/ksplice/
> original files and signed with their key
> 
> from the included README:
> 
> Ksplice
> Copyright (C) 2007-2009  Ksplice, Inc.
> Authors: Jeff Arnold, Anders Kaseorg, Tim Abbott
> 
> This program is free software; you can redistribute it and/or modify
> it under the terms of the GNU General Public License, version 2.
> 
> For more information about Ksplice, please see <http://www.ksplice.com/>.
> 
> Installation instructions:
>  $ ./configure
>  $ make
>  $ make install
> 
> Notable Build Dependencies:
>  - GNU binary file descriptor (BFD) library (version 2.15 or later)
>    (available in Debian's binutils-dev package and in other distributions)
> 
> Tru

I have worked for a few days on the KSplice code. But I'm stuck writing a tool 
for analyzing patches.

The problem I faced was that if you have a few simple patches that don't alter 
major structures in the kernel it self you can simply create a ksplice module 
from those patches and load it. It works like a charm.

But when you start putting more and more patches, inevidablly you reach a 
point where there is a patch that for example changes the VFS layer or the 
network layer or somthing like that. At that point you need to write 
additional code so the ksplice module generator would know how to handle the 
upgrade. 

For some patches it is fairly trivial... for others it is quite complex.

So what I decided to do is firs separate the 3 types of patches:
  1. Ready to apply (no major changes to structures in the kernel)
  2. Patches that require additional code (minor or trivial changes to 
structures in the kernel)
  3. Patches that require manual review (major changes to structures in the 
kernel or possible conflicts with other parts of the kernel)

It would be great if we put the project in GitHub or Gitorius so we can all 
collaborate on the solution.

Best regards,
Marian Marinov
CEO of 1H Ltd.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20110722/87b24167/attachment-0007.sig>