On Fri, 25 Apr 2008, t35t0r wrote:

> Kernel patches are hardly random. Ksplice probably works similarly
> to how run-time memory patchers/loaders work.

Not quite... from the patch to the binary code, you have a long way
which depends on compilers, environment, config files, etc. You have
to get the exact same combination of all of these that was used to
compile the running kernel in order to have a good chance of not
creating binary code that messes up more than fixes that kernel.

> They try to do this already with normal kernel updates. Only RHEL
> (ksplice) updates would be supported obviously.

Sure, but they have to create such a fix for each of the kernel
updates as well: for RHEL 5.1 the original kernel was -53, but there
were several updates later (f.e. -53.1.4, -53.1.6, -53.1.13, -53.1.14)
- while RH recommends to always run the latest, the clients are not
always able to do it.

Plus you'll have the situation that a ksplice patch was applied to a
kernel - what version is that kernel from that moment on ? Is it safe
to apply further ksplice patches to it ? Are there ksplice patches
that obsolete other ksplice patches ? When I want to install a new
machine, do I go with the latest kernel version or go with the
original one and apply all the ksplice patches to make it look like my
other machines that already run this combination ?

--
Bogdan Costescu

IWR, University of Heidelberg, INF 368, D-69120 Heidelberg, Germany
Phone: +49 6221 54 8869/8240, Fax: +49 6221 54 8868/8850
E-mail: bogdan.costescu@(protected)

_______________________________________________
rhelv5-list mailing list
rhelv5-list@(protected)
https://www.redhat.com/mailman/listinfo/rhelv5-list