Hello Scott,
Am 20.06.2014 01:45, schrieb Scott Wood:
On Thu, 2014-06-19 at 12:34 +0200, Heiko Schocher wrote:
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 ready
e) 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 ... :-(
This is why I suggested taking one big diff rather than going
patch-to-patch. Then you don't have to resolve the same conflicts over
and over.
You should also exclude files that U-Boot doesn't have, and include
header files that are relevant.
Yep.
"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).
If you fetch the Linux tree into your U-boot repository, then -3 will
work.
Ah, try this.
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 ...
If the conflict is due to a change that applies to code that is missing
because it doesn't make sense in U-Boot, then just delete that conflict
and move on. Unlike having the change silently apply to an ifndef
region, you can first evaluate the change to see if it should apply to
some alternative U-Boot version of the code.
Ok, I step into this direction.
Thats the question we must solve, do we want the complete Linux MTD code
in U-Boot and mark not used code?
No.
Ok, prevent this.
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=7d2357c1999ff1f93f795282526230a8bd176106
Hmm.. what was the Linux base of this ?
See commit dfe64e2c89731a3f9950d7acd8681b68df2bae03 "mtd: resync with
Linux-3.7.1"
Ah, yes, there are also UBI files.
and ubifs from 2009?
http://git.denx.de/?p=u-boot.git;a=history;f=fs/ubifs;hb=7d2357c1999ff1f93f795282526230a8bd176106
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 ...
CCing Kyungmin who is the UBI maintainer.
Thanks.
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...
I don't know about ubifs, but the core NAND code (and apparently the
core UBI code) is currently synced with Linux 3.7.1.
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
It is different because "work in the U-Boot specific changes" is a
manual, error-prone step compared to letting git do most of the work.
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 ...
Again, there's no need to go patch-by-patch. We haven't done so on
prior updates.
I try it this way.
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
