On Wednesday 29 September 2010, Linus Walleij wrote:
Nicolas Pitre wrote:
Indeed. And that's exactly what I'm looking for in order to produce the linaro-next kernel tree. The linaro-next tree is discarded and rebuilt from scratch by merging together a bunch of development trees on a regular basis. I'd like to add your up-to-date tree to the lot.
We currently don't have anything like a git, what we have is this patchstack against Rothwells next-tags: http://userweb.kernel.org/~linusw/st-ericsson/
This consists of the patches we have considered to be in such a good shape that we have sent them off to the different mailing lists and subsystem maintainers.
NB: this is on top of the stuff we already have pending in next, which is currently actually a lot.
Right now we have ~49 patches pending in the latest next tag and ~27 patches in the additional patch stack (i.e. stuff under review).
I'm rebasing this patch stack agains Rothwells tree at irregular intervals.
How many trees are there that have your patches in linux-next? I'm guessing that we have some of them in linaro-next already, so maybe we can add the others as well.
Maybe I'm just not understanding some easy way out of cross- subsystem dependencies, but the way I'm experiencing it is that we have done the simple drivers already, the stuff we have left is all of the type where we must have some special header file for the driver platform data creating a cross- subsystem dependency to the ARM tree. Any incremental fixes once the driver is in are usually a breeze to merge and maintain.
Yes, this is a known problem with the way that devices are handled on ARM. Normally the platform code wouldn't have to known anything about the devices except for essential things like the interrupt controllers.
What we need here is a generic way to find out what devices are present other than encoding it into the platform. The flattened device tree is one solution to this, but it seems that it will take a long time before you can use it.
We are making this even more elaborate by trying to push stuff like DMA into drivers/dma/* and GPIO expanders into drivers/gpio/* instead of just slamming all hairy cases into arch/arm/* like many platforms have done previously...
Yes, that is very good.
Any hints on how to get out of this and create a simple git tree or set of trees is welcome, I have yet not found any.
I think you need to stop basing on top of linux-next and move to basing on top of the smallest possible set of trees other than mainline.
Today's series seems to apply almost cleanly on top of Russell's ARM tree, so as a start, you can create one git tree based on his and apply all your patches on top.
Since the base also in linaro-next, Nicolas can easily merge it. If you have dependencies on other trees, say the MMC tree, then split out the MMC related patches into a separate series and apply them on the mmc-next tree, and put them into a different branch in your git.
Create a master branch in your git than merges all the separate branches for people to test out your code.
Things get a bit hairy if the tree you base on gets rebased. Most maintainers do this very rarely, so you should be fairly safe.
You can also have multiple branches based on Linus Torvald's tree, e.g. for things like i2c or mtd that do not depend on changes in Russell's or anyone else's tree.
Arnd