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: [EMAIL PROTECTED] _______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
