Quote:
Originally Posted by pepijndevos
Merging with chris's kernel does not make sense. He took the lab126 kernel and added some stuff.
What I'm trying to do is get the lab126 kernel in a git repo that has history and future, so git can do some of the heavy lifting of merging v2.6.31+.
I just tried doing this with v2.6.31-rt11, which has a few less conflicts. After overwriting that with the lab126 version, I merged a few small increments, and finally tried to make the leap from 31 to 33(there is no 32-rt), by running "git merge v2.6.33-rt8".
It has a lot of conflicts. Even in arch/x86 and arch/powerpc 
I installed a three-way merge tool and did "git mergetool", but I'm just not enough kernel hacker to do it. I merged some docs, C and even ASM code, but then I hit a ton of files in arch/arm/mach-mx25/ that where added on both sides or had non-trivial changes on both sides.
I will push my minor increments to github, maybe it is of use to someone. I can't take it any further though.
This is the most recent v2.6.31.*.-*rt
https://github.com/pepijndevos/kindl...a6b0c4444ea452
The next step would be v2.6.33 and possibly v3.0.10, but I would be content with v2.6.33.
Not going to happen I guess. I'll just see what I can do with an old v2.6.31 kernel. Get Chris' kernel and a Debian chroot, and it wont be too bad. |
I'll have to check what kernel buildroot is building right now but I still don't get why you cant just use that and merge in chris's changes if that is what you are after. (EDIT: Maybe I will read this back one day and "GET IT")
I did an example of a big 3 way merge on the "Better Busybox" thread.
I was thinking to just diff out Chris' changes and merge them back into the source (pre-buildroot "make") and get BR to do all the heavy lifting.
Anyway that project is on the backburner for RSN, don't have a 4 yet but assuming I get my hands on one then perhaps I can get excited about this too. thanks for sharing