Andy Green wrote: > Somebody in the thread at some point said: > | Mirko Vogt wrote: > |> Is there a location where all the atomar patches related to kernel > |> 2.6.28 / Openmoko are stored? > | > | We stopped keeping patches in that way quite a while ago already. > | So if you're looking for what Openmoko did, just checking out the > | tree is indeed your principal option. > | > | It shouldn't be too bad, since most of our code is actually in new > | files, e.g., complete drivers or machine/platform-specific stuff. > | Fixes to code that's already in mainline are usually submitted > | upstream right away, so before long they should disappear from > | "our" set of changes. > > Right, we are starting to push chunks of our stuff upstream as well. > > What we have is incremental patcheset now, but we do have a history. > > You can use git diff to arrive at a flat diff set, depending on what > you're trying to do (ie, see what we alter in mainline as opposed to > what drivers we add) that can be enlightening. > > There's also still the old patchset upleveled for 2.6.28 in > mokopatches-tracking branch in git, but that's "half the story" now. > > http://git.openmoko.org/?p=kernel.git;a=shortlog;h=mokopatches-tracking > > Maybe explain what you're trying to do with what you're looking for and > there is another way to come at it. > > -Andy
Thanks Andy and Werner for yor replies! What I actually want to do: Currently I'm working on getting the kernel built within a(nother) buildroot-environment. This buildroot itself patches the vanilla-sources heavily. The problem I actually have is, that I've _two_ patchsets for the kernel 2.6.28: - a well orginzed set of atomar patches provided by the buildroot for kernel 2.6.28 (~70 patches) - the patchset of OM extracted from git with non-atomar patches (which needs to get applied on the already patched sources) (~620 patches) Some patches are - surprise - conflicting because they touch the same code (which results in patch-errors or at least compile-errors) or - the other case - they touch different parts of the same functionality (welcome to the runtime debug horror). Now I need to get the OM-patches applied on the already patched vanilla sources. I hope(d) to have e.g. 1 patch for getting glamo working, 1 patch for sound, 1 patch for $hardware_which_is_not_supported_by_vanilla_kernel, etc. That would help me a lot, because: - I could try to integrate, if necessary change and debug the Openmoko-patches step by step / patch by patch (so problems could be traced down to applied patches) - I don't have to figure out which patches must be applied at once, because they're mabe touching the same functionality and only work together How would you start here? It seems to me impossible to get that done when scrolling through the via git-format-patch created patchlist. I also saw lot's of patches extracted from git which just change some defconfigs. In my view they're not related to the "normal" kernel-patchset and just increase confusion when they could not be distinguished from "functionality"/source-patches. Thanks a lot mirko (still the other one :)) -- This email address is used for mailinglist purposes only. Non-mailinglist emails will be dropped automatically. If you want to get in contact with me personally, please mail to: mirko.vogt <at> nanl <dot> de
