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

[Tom Rini]

On Mon, Jun 30, 2014 at 06:09:53PM -0500, Scott Wood wrote:
> On Tue, 2014-07-01 at 00:56 +0200, Wolfgang Denk wrote:
> > Dear Scott,
> > 
> > In message <1404159636.2435.165.camel at snotra.buserror.net> you wrote:
> > >
> > > > I agree that #ifdef's should be avoided, but then here they also serve
> > > > a documentation purpose as they clearly mark areas of code that are
> > > > specific to U-Boot, or that are not used in U-Boot.
> > > 
> > > git diff can do that too, without reducing readability or increasing the
> > > likelihood of mismerges.
> > 
> > (git) diff needs a reference to diff against. Maybe I missed some
> > earlier comments about that, but how exactly should this be done
> > here?
> 
> When the code is synced, the corresponding Linux SHA1 or tag should be
> placed in the commit message.  This is the case for the NAND code.
> Unfortunately it has never been true of the mtd/ubi code, but this
> do-over in those trees is an opportunity to fix that.
> 
> > If we want to have strictly bisectable code in mainline, I don't
> > really see how to provide an unmodified source reference to show the
> > U-Boot specific diffs.
> >
> > Can you please explain (maybe again, sorry) how you think the code
> > update should be done do both allow such a git diff and remain
> > bisectable?  The ways I can see all require a non-working / non-com-
> > piling intermediate step.
> 
> There is no intermediate step.  
> 
> 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) ?  (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.

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.

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140707/9691f12c/attachment.pgp>