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@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.