On 11/19/2011 6:44 AM, Karanbir Singh wrote:
> On 11/19/2011 01:09 PM, Andreas Balg wrote:
>> I remember Karan got the ksplice-code in order to be able to fork this
>> great technology for CentOS and not let got Oracle all alone with this.
> There have been issues..
I'll add my two cents.
>> So what happened the last weeks/months regarding this great idea ? Iâ€˜d
> 1) Corey has been doing some work on this - we managed to get a couple
> of test patches rolled into modules, ship them over and keep the
> machines going - but being able to do that for the large patches coming
> from RH has been very hard - not the least because neither Corey nor I
> have enough kernel development foo to keep things moving forward. The
> merged patch from RH does not help at all.
I posted a "how to" with the ksplice raw utils a little while ago:
It's fairly easy to build one update. Stacking updates is a different
issue, and doing large patches is also another issue.
I'm very interested in getting deeper into the kernel dev foo, but at
the present I'm currently occupied with another project.
> 2) The tool chain published by ksplice/oracle is incomplete. There are
> atleast 3 efforts, that I know about, to chase them up to get the
> complete toolchain released ( and this is the one that they *are* using
> and shipping at the moment, still with GPL license code. So join the
> effort : signup a fedora machine or an ubuntu machine, get their free
> stack on there, then ask for the source. Document the process, blog
> about it and canvas for local support. It would help.
The main issue is the toolchain we have only works for the EL5 kernel.
It doesn't work for EL6, nor the current fedora, as it's obviously
missing code changes.
The internal kernel code changes enough between major releases that I
imagine the development of the ksplice toolchain has been pretty far
past what we have. Our git repo with the code has nothing more than what
oracle releases here:
The fact that they haven't released any further source code is actually
a violation of the GPL. I explain some details here:
The violation is simple; they release binary code that was compiled with
GPL code (ie; kernel source code) but don't release a) the patch they
compiled and b) the method(s) of compiling it. The GPL is a pretty viral
So, any support we can get on this front is appreciated.
> 3) There might be other, better ways of achieving the same result -
> atleast one of which has prior art going back into the late 1960's - but
> between both of the us, it again boils down to time/resource and kernel
> development foo.
A while ago I tinkered with a different approach, and it sort-of works.
I stopped development on it when I realized that it isn't good enough
(as is, anyway) to be a comparable replacement. It's on github if anyone
The code for it is based off of a lkm-rootkit method that I also use in
my tpe-lkm project:
It's a nice and easy security feature. But now I'm getting off topic.
> Finally, there have been pressures on various fronts keeping us from
> working on this much further. We also noticed that there was and is very
> little interest in ksplice itself. While it sounds really cool very few
> people really need something of this nature. And given that you cant
> really just keep patching, all the time, all kinds of patches - the idea
> that your machine will stay online 24/7 is a bit of mis-selling really.
I honestly think that people don't trust the technology enough to have
interest in it. IMHO it's solid stuff, but it has to be done right, and
the various factors KB talked about is what's keeping us from making a
big push for it.
>> personally and professionally be interested in using it for our
>> deployments but also to contribute where possible â€“ we have no
>> kernel-development knowledge here to help out but maybe we can help in
>> other ways as well.
Drop me a line directly to see what we can work out.
>> Is there already any project fort he fork going on or did the idea die
>> or sleep silently the last few weeks ??
> things have been ticking along, slowly, in the background. If there is
> enough interest and if we can get a few people involved in there with
> the require skills - we should have a chat about it, split up the tasks
> and all of us go away do something about those tasks. Having said that,
> I am still quite keen to see oracle/ksplice actually release their code.
>> Curious greetings from switzerland,
> Hello from a surprisingly sunny London!
Hello from a snow-covered Utah
> - KB
> CentOS-devel mailing list
CentOS-devel mailing list