[U-Boot] [PATCH v4 0/3] mtd, ubi, ubifs: resync with Linux-3.14

[Scott Wood]

On Mon, 2014-07-07 at 12:12 -0400, Tom Rini wrote:
> On Mon, Jun 30, 2014 at 06:09:53PM -0500, Scott Wood wrote:
> > The unmodified source is in the Linux tree -- most likely in a more
> > accurate/complete form than the ifdefs convey, since minor differences
> > and subsequent local changes are unlikely to be marked.
> > 
> > You can either fetch the Linux tree into your local U-Boot repo (or vice
> > versa) so that git diff can compare them, or you can check out separate
> > repositories to the proper tags/SHAs and use ordinary diff.  It's not
> > something that I'd expect one to want to do very often, though.  Usually
> > you want to know how things work in the codebase you're working on, or
> > you want to compare some specific aspect of the code which can more
> > easily be done manually.
> 
> So an example of this would be doing say:
> $ git diff 3dad234 drivers/mtd/nand/nand_base.c
> 
> Where 3dad234 is the last kernel commit to U-Boot
> drivers/mtd/nand/nand_base.c where we synced right (and we've fetched
> the kernel sources into this repo as well) ?  

3dad234 was a cherry-pick, not a sync.  The last sync was v3.7.1.  To
see the differences as of the last sync, do this:

git diff cc8605070 dfe64e2c drivers/mtd/nand/nand_base.c

> (This commit is
> also valid for atmel_nand.c and I looked over the results there too..).
> 
> We must, really, follow the general rule where when we sync stuff from
> the kernel we say what the commit we synced with is, for UBI/etc.  We
> may not have been for forever but the last time we also said that tag it
> was against.

Yes.  Unfortunately this can create misleading commit messages when some
files are synced to a Linux SHA, and other files are merely touched to
avoid resulting breakage.  That SHA should be valid for core nand files,
but probably not for most drivers.  I don't think we've ever done
centralized syncing of nand drivers.

Future merge commits should be more explicit about which files were
synced.

> But how we denote U-Boot vs Linux Kernel differences is somewhat up to
> the subsystem maintainer.  We must be careful when syncing back.  But
> looking over the above diff, as a more casual nand developer, I wish
> there was more in-code context about why we are different.  But that's
> just me and how I develop.  It would be pretty easy (but not quite
> easily scriptable) to whack out the #ifndef/else/endif __UBOOT__'s,
> commit that, and be back to having the output one wants, if that's how
> one works.

FWIW, back when the nand code had such ifdefs, there was rarely any
explanation for the difference -- it was just a statement that a
difference existed.  Nor could I trust that all of the differences were
documented that way, or that the code in ifndef sections was kept up to
date.

Beyond readability and usefulness, my concern is that the ifndef code
will cause mismerges in the future, if the if/else section is large
enough that git doesn't flag it as a conflict, and thus needed changes
don't get applied to the U-Boot side of the if/else.

> In sum, if Heiko is going to be owning UBI/related code and syncs,
> whatever makes life easiest on _him_ to make sure we don't have
> regressions is fine with me (within reason, and this seems to be within
> reason).  Do not get me wrong please, I appreciate all the time you've
> spent thus far in U-Boot and wish and want you to comment / review /
> advise as you're still able to find time.  But if someone else is taking
> up doing the re-syncs it needs to also fit their workflow.

Yes, of course.  For code outside drivers/mtd/nand, I'm just providing
advice, based on what I felt did and did not work well in the nand code.
That goes for nand as well if and when someone actually takes over the
custodian role -- I said as much earlier in this discussion.  If that
helps motivate Heiko or someone else to formally take over the role
sooner rather than later, then great. :-)

In the absence of a change in custodianship, my experience has been that
a different person ends up submitting a sync each time.  I would have
also done an occasional sync myself if someone requested one based on
missing important changes, but usually people have shown up with patches
instead.

-Scott