How to add an unsupported mach to kernel source

To elaborate, I have a linux kernel source 2.6.30 for an ARM device but I want to compile an older kernel (2.4.20). I have the arch/arm/mach folder but can I, in a sense, splice it into an older kernel without errors?

I tried looking for a guide on this but I didn't have much luck since I'm not really sure what to search for.

Thanks,
Jason

Originally Posted by dirtyrobinson can I, in a sense, splice it into an older kernel without errors?

There's 7 years worth of non-trivial development between kernel 2.4.20 (rel.: 2002) and 2.6.30 (2009) including conceptual changes, bug fixes, improvements, optimizations, versioning changes, function renaming and code location changes. So in theory the answer is yes but in practice the answer is no. Back porting code between major kernel versions should be the exclusive domain of those who truly understand kernel internals, truly understand the consequences and have no viable alternative. Running a 2.4 kernel is ill advised, well maybe not if you're a vendor in a specialist embedded device niche market. OTOH if you're an ace coder already then maybe this could provide an interesting crash course introduction into kernel programming. And Linux always has a need for more kernel programmers...

I never looked at the dates so I didn't realize there was such a difference in time between the 2 releases. I have a device with an application running on MontaVista and while I can get the operating system to boot on a different device, the application fails to start. Naturally, I thought the issue might lie with the kernels being different (the board that runs the application is 2.4.20 and the new board is 2.6.30), so I started looking on what it would take to add the machine files from my 2.6.30 source to the untouched linux kernel source 2.4.20. I love messing around with this stuff but I didn't know what keywords to actually search for.

Would you know of any links to some great references on this subject that would give enough information that I could try my luck on back porting?

Originally Posted by dirtyrobinson (..) while I can get the operating system to boot on a different device, the application fails to start. Naturally, I thought the issue might lie with the kernels being different (..)

So it's only assumptions? Are you sure that's the most efficient approach for troubleshooting? Personally I'd first aim for device logs / (serial line?) debug data and such...
And no, I don't know of any references wrt back porting. I think it's like with a lot of jobs: you may have had formal training (or not ;-p) and you may be qualified (or not ;-p) and in the end it's only doing actual work that'll teach you the hurdles, pitfalls and gotcha's.

Well, "dirty," perhaps the best response is to step back from the lake with a number of quick steps, now that someone's warned you that there are piranhahs in that innocent-looking pool (with the bones on the shoreline). Look around for another way to get where you're going.

"The problem to be solved here" is ... "why does this application fail to start?" It would surprise me rather a lot to find that it actually has anything to do with the kernel or OS-version at all. Probably a purely user-land difference in libraries and so-forth. "Your original idea sounded like an okay strategy at first glance," but lots of original-ideas are like that.