>From the bottom....
>>> Keith Owens wrote:
>>> Reverse engineering a patch out like this is messy, especially when
>>> other patches hit the same files. It is a lot easier to work from the
>>> pristine tar ball then apply patches forwards. Have you asked Mandrake
>>> where their tar ball + patches are for the kenrel?
I agree, this looks possible, but would require careful work to make sure each
file is correct.. Especially since the definition of correct may be hard to
determine without the patch files. But, with care perhaps I won't introduce
more problems than I'm taking out... I had considered just booting a pristine
2.6.3 kernel under the rest of Mandrake, but that also seems like a fishing
expedition with new problems in places that I will break by removing all of
Madrakes patches... Sounds like I would be expanding the effected areas, not
reducing it... Also sounds like some experimentation is in order..
So, I will ask Mandrake if their patch set is available, and if it's not, I
will do the kernel hack myself after I fix the driver... I will just get out my
stone knives and bear skins and use a sorted symbol list with listings from
objdump intermixing the assembly with the source... It's slower, but at least
I'm not adding more unknowns..
Is this typical for Mandrake? Seems like releasing a butchered patch speaks of
a really bad test plan before release...
-Charlie
----- Forwarded message from "Dunn, Charles" <[EMAIL PROTECTED]> -----
Date: Wed, 23 Jun 2004 11:08:16 -0400
From: "Dunn, Charles" <[EMAIL PROTECTED]>
Reply-To: "Dunn, Charles" <[EMAIL PROTECTED]>
Subject: FW: Mandrake 10.0 (2.6.3-7mdk) and no symbols
-----Original Message-----
From: Keith Owens [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 22, 2004 6:11 PM
To: Dunn, Charles
Cc: [EMAIL PROTECTED]
Subject: Re: Mandrake 10.0 (2.6.3-7mdk) and no symbols
On Tue, 22 Jun 2004 11:02:45 -0400,
Charles Dunn <[EMAIL PROTECTED]> wrote:
>Keith Owens wrote
>> The kdb patch in linux-2.6.3-7mdk has been badly butchered. Although
it
>> claims to be kdb v4.3 for 2.6.3, it is closer to an unofficial kdb
>> v4.1 patch that Jim Houston did against 2.6.0-test4. It looks like
bits of
>> the real kdb v4.3 patch did not apply so were ignored, keeping an old
version
>> of the patch in some places.
>
> Uh oh... Without the original patch that they used, is it even
possible for me
>to remove what they did?? Perhaps the short term solution for me would
be to
>try and fix the symbol handling in the butchered version.. Maybe the
right
>solution is to switch to Red Hat..
Most distributions use the model of a pristine tar ball plus patches,
all wrapped up in a src.rpm. That makes it easy for the user to backout
or replace individual patches. I cannot find a Mandrake kernel src.rpm
with seperate patches, the closest I could get was a kernel-source rpm
with all the patches already applied.
If you want to hack the source yourself,
rm -rf arch/i386/kdb Documentation/kdb kdb
rm -f include/linux/{kdb*,dis-asm}.h
rm -f include/asm-i386/{kdb*,ansidecl,bfd}.h
Edit these files and remove all traces of KDB.
Makefile
init/main.c
mm/memory.c
kernel/printk.c
kernel/kallsyms.c
kernel/exit.c
kernel/sched.c
kernel/module.c
kernel/signal.c
kernel/sysctl.c
scripts/kallsyms.c
scripts/Makefile
include/linux/sysctl.h
include/linux/console.h
include/asm-i386/ptrace.h
include/asm-i386/mach-default/irq_vectors.h
include/asm-i386/kmap_types.h
drivers/serial/8250.c
drivers/char/sn_serial.c
drivers/char/keyboard.c
arch/i386/Makefile
arch/i386/kernel/vmlinux.lds.S
arch/i386/kernel/traps.c
arch/i386/kernel/smp.c
arch/i386/kernel/smpboot.c
arch/i386/kernel/reboot.c
arch/i386/kernel/nmi.c
arch/i386/kernel/io_apic.c
arch/i386/kernel/i8259.c
arch/i386/kernel/entry.S
arch/i386/Kconfig
Be careful of any #ifdef CONFIG_KDB with an #else clause, you need to
retain the #else clause.
After removing kdb code, compare the above files against a standard
2.6.3 kernel. If you find any changed lines around the area where you
removed the old kdb patch, make it look like standard 2.6.3 code where
possible. Mandrake have applied other patches to some of these files,
so not all differences will be due to removing the old kdb patch.
Finally apply the real kdb v4.3 common-2 and i386-1 patches. Where
Mandrake have changed the same files, resolve any patch conflicts.
Reverse engineering a patch out like this is messy, especially when
other patches hit the same files. It is a lot easier to work from the
pristine tar ball then apply patches forwards. Have you asked Mandrake
where their tar ball + patches are for the kenrel?
----- End forwarded message -----
---------------------------
Use http://oss.sgi.com/ecartis to modify your settings or to unsubscribe.
