Hello Tom,
Am 23.06.2014 17:05, schrieb Tom Rini:
On Sun, Jun 22, 2014 at 09:36:43AM +0200, Wolfgang Denk wrote:
Dear Heiko,
In message53A67ED9.2090705@denx.de you wrote:
And I have no chance to detect this difference, when using "git am -3 ..." ... it just remains in the code ...
I vote for copying the linux files, marking U-Boot specific code with __UBOOT__ ...
Given the complexity of the code - and of the changes added in U-Boot to the original (old) Linux code (which were done over a period of time) - I think indeed that your original approach is the better one; better both in the sense of requiring less efforts (for creating and verifying that all chanes were covered), and less risk to miss individual modifications either from the Linux or from the U-Boot side.
Scott, I agree that your suggestion is what usually should work fine, but here it apparently fails in a number of places that would be time consuming to sort out - and I would expect that the same would happen again whenever we update to another new version of the Linux code base. So I think we should stick with Heiko's approach here; it documents clearly what he did, it looks complete, and it is working. I think it would be a waste of time to redo all the work, just differently.
OK, lets try this. One worry at the back of my mind is the fallout we had when we re-synced to v3.7.1 and tested things as best we were able to prior to merge. I think it's too late in the cycle to pull this in
Yes I fear such fallout too ... I could also test on some boards only, the rest is compile clean only ... thats the reason why I had the sync serie as RFC ... maybe we create a mtd-test branch? But on the other hand, things maybe get tested only, if they are in mainline ...
for v2014.07, but lets get something in for v2014.10. And since v3.15
Yep, that was my plan too.
is already out, lets do (as part of testing our theories out), a follow up patch to sync up with v3.15. And finally, I think we need, in order to keep this pain point down, sync per kernel release.
Ok, I had prepared a v5, posting it soon.
I try to do also to prepare a seperate sync with v3.15 patch, but give me some time ... also I found a bug in current v3.16-rc1 kernel, using ubi fastmap, see:
"UBI: fix rb_tree node comparison in add_map commit buggy?" http://lists.infradead.org/pipermail/linux-mtd/2014-June/054348.html
So current v3.16-rc1 kernel could not attach a ubi volume using ubi fastmap and created with a kernel not having commit 604b592e6fd3c98f21435e1181ba7723ffc24715 applied ... which is the case for v3.14 ... with my fixup, a v3.16-rc1 kernel could again attach a v3.14 kernel or U-Boot (with my v3.14 sync patches applied) created ubi volume ...
Maybe we wait with the sync, until this is sorted out?
To sync us with each kernel release would be a good idea, but the problem would be, to find time for it ...
bye, Heiko