Hello Tom, Scott,
Am 18.06.2014 23:42, schrieb Tom Rini:
On Wed, Jun 18, 2014 at 04:24:39PM -0500, Scott Wood wrote:
On Wed, 2014-06-18 at 09:55 +0200, Heiko Schocher wrote:
Hello Scott,
[snip]
history to see what Linux version corresponded to the last mtd sync, and generate a diff relative to that.
I think, we should have the linux code as the reference, and on top of this, we should add our U-Boot changes ... Thats the reason for the git tree [1].
One of the strengths of version control is the ability to do three-way merges, rather than throw away the downstream code and reassemble it from scratch.
Indeed.
[snip]
What does #ifndef __UBOOT__ tell you that a diff between the U-Boot and Linux files, as of the SHA1 that was last merged into U-Boot, doesn't tell you?
There we have the "simple copy from linux patch" [2]. It overwrites the U-Boot specific changes, yes, but only in an intermediate step in this git tree ... (Maybe I should add in the commit message, that this is a simple copy from linux sources)
Then a U-Boot specifc patch [3], which introduces again hopefully all U-Boot specific changes... so *all* U-Boot specific changs are documented. At last a seperate licencse file patch [4] added which changes the license text.
My hope was, that future linux mtd syncs could look like:
a) copy new linux source files to u-boot tree [1] (make a new branch go back to commit [2] ... and copy new files from linux) (commit this, to have all linux changes since last sync with linux documented) b) apply [3] and fix problems All U-Boot changes documented c) apply [4] and fix problems d) add newly added U-Boot specific patches (mark them with _UBOOT_ define if they are not yet marked with it) (maybe squash them to step b ?)
-> new git tree readye) squash all patches into one patch and send it to mainline ... so the mainline patch has only new changes with all U-Boot specific changes.
If you take over as NAND custodian, you can of course do the updates as you please (unless Tom or Wolfgang disagree), but until then I insist on doing a proper merge, and not littering the code with #ifndef __UBOOT__.
Thats sounds easy ... and you have all linux and all U-Boot changes visible and documented ... I must admit, I did not tried your proposal to look into the linux changes since the last mtd sync ... but that sounds the more tricky way to get this sync, as the history can be long ... and shouldn;t be the result the same?
Why does the length of the history matter? I'm not asking you to go patch by patch. Just take a diff between the SHA1 of last merge and the SHA1 you want to merge now, and apply that patch.
But it's not even that hard to do so! git format-patch -o mtd-resync v3.7..v3.14 drivers/mtd/nand will give you only the relevant patches,
"git format-patch -o mtd-resync v3.7..v3.14 drivers/mtd/nand" results in 440 patches ... :-(
"git am" first patch immediately fails ...
Ok, one step back ... I try only "drivers/mtd/mtdcore.c":
$ git format-patch -o mtdcore v3.7..v3.14 drivers/mtd/mtdcore.c mtdcore/0001-mtd-convert-to-idr_alloc.patch mtdcore/0002-mtd-add-const-qualifier-to-a-couple-of-register-func.patch mtdcore/0003-mtd-mtdcore-remove-few-useless-ifdef-s.patch mtdcore/0004-mtd-merge-mtdchar-module-with-mtdcore.patch mtdcore/0005-Include-missing-linux-slab.h-inclusions.patch mtdcore/0006-drivers-avoid-format-string-in-dev_set_name.patch mtdcore/0007-mtd-add-a-new-sys-node-to-show-the-ecc-step-size.patch mtdcore/0008-mtd-add-MTD_MLCNANDFLASH-case-for-mtd_type_show.patch mtdcore/0009-mtd-Move-major-number-definitions-to-major.h.patch mtdcore/0010-mtd-remove-duplicated-include-from-mtdcore.c.patch mtdcore/0011-mtd-convert-to-use-ATTRIBUTE_GROUPS.patch $
Only 11 patches, great ... but:
$ git am -3 mtdcore/0001-mtd-convert-to-idr_alloc.patch Wende an: mtd: convert to idr_alloc() fatal: sha1 information is lacking or useless (drivers/mtd/mtdcore.c). Dem Projektarchiv fehlen notwendige Blobs um auf eine 3-Wege-Zusammenführung zurückzufallen. Kann nicht zu 3-Wege-Zusammenführung zurückfallen. Anwendung des Patches fehlgeschlagen bei 0001 mtd: convert to idr_alloc() Die Kopie des fehlgeschlagenen Patches befindet sich in: /home/hs/i2c/u-boot/.git/rebase-apply/patch Wenn Sie das Problem gelöst haben, führen Sie "git am --resolved" aus. Falls Sie diesen Patch auslassen möchten, führen Sie stattdessen "git am --skip" aus. Um den ursprünglichen Zweig wiederherzustellen und die Anwendung der Patches abzubrechen, führen Sie "git am --abort" aus. pollux:u-boot hs [mtdubiubifs_try] $
$ patch -p1 < mtdcore/0001-mtd-convert-to-idr_alloc.patch patching file drivers/mtd/mtdcore.c Hunk #1 FAILED at 349. 1 out of 1 hunk FAILED -- saving rejects to file drivers/mtd/mtdcore.c.rej $
:-(
and they should mostly apply, and then you can squash them after the fact.
I try to try this ASAP and report (first steps see above ...). But as a lot of linux code is missing in U-Boot code, I feel, that a lot of chunks will not apply ... but maybe (hopefully) I am wrong ...
So therefore I copied and introduced the complete linux code, because it is the easier way for generating this patch...
What I new introduced is: mark in U-Boot unused/different Code with __UBOOT__ ... to get faster, U-Boot relevant changes, by simple looking into the diff ...
Thats the question we must solve, do we want the complete Linux MTD code in U-Boot and mark not used code?
If no, I delete this pieces of code...
Hmm... looking in the history of drivers/mtd/ubi it seems the code is basically from 2008! http://git.denx.de/?p=u-boot.git;a=history;f=drivers/mtd/ubi;hb=7d2357c1999f...
Hmm.. what was the Linux base of this ?
and ubifs from 2009? http://git.denx.de/?p=u-boot.git;a=history;f=fs/ubifs;hb=7d2357c1999ff1f93f7... Base: "2.6.29-rc6" ... uh, very, very old!
I see there no real syncs with newer linux code ... is this true? Just some fixups ...
Hmm reading the commit mesage from 9eefe2a2b37a838558e3d213a9f5519503d0c180: "UBIFS: Implement read-only UBIFS support in U-Boot"
"The U-Boot UBIFS implementation is largely a direct copy from the current Linux version (2.6.29-rc6). As already done in the UBI version we have an "abstraction layer" to redefine or remove some OS calls (e.g. mutex_lock() ...). This makes it possible to use the original Linux code with very little changes. And by this we can better update to later Linux versions.
I removed some of the Linux features that are not used in the U-Boot version (e.g. garbage-collection, write support)."
Sounds like my current approach ... Ok, again, not used code is deleted.
I really fear a patch "git format-patch -o ubifs-resync 2.6.29-rc6..v3.14 fs/ubifs" (The result from this command are 355 patches ...)
So, in sum, this are 795 patches + missing ubi patches which must be applied/reworked/reviewed... Sounds painful...
So another question is: How to generate an update-sync patch:
version a): - copy the new linux files from Linux v3.14 to U-Boot - work in the U-Boot specific changes - make a patch from this
Is this really different to:
version b): - git format-patch -o mtd-resync v3.7..v3.14 drivers/mtd/nand - apply them - make a patch from this
Currently it is differrent, as I introduced the complete linux code and marked unused/different code in U-Boot with __UBOOT__. If I delete this pieces ... version a) and b) should be the same.
I try it ... if I not give up due to count of patches ...
Maybe it was not a so good idea to remove the "RFC" state from this patches ;-)
bye, Heiko