[U-Boot-Users] [PATCH v3] Fix initrd length miscalculation in bootm command when using a dtu

[Stefan Roese <sr@denx.de>]

Hi Timur,

On Friday 04 May 2007 15:25, Timur Tabi wrote:
> I'm glad you fixed the bug, so I'll just add a few comments:
> > Your comment is actually wrong. The use of "len" is not limited to
> > that purpose.
>
> If you apply my patch, then the comment becomes correct.  My goal was to
> lock the variables 'len' and 'data' into one purpose.  The reason the
> bug existed is because the other developer didn't realize this.  He used
> 'len' thinking it was available.  In a sense, I was trying to implement
> some "defensive programming", so that the next time someone hacks up
> do_bootm_linux(), he won't re-introduce the bug.
>
> Now, you might say that that won't happen again, but I disagree.  I
> think it can, for two reasons:
>
> 1) It happened once already, last year.  You approved and applied a
> patch which does overwrite the variable.
>
> 2) The libfdt code introduced a number of other bugs relating to dtu
> usage, which have not yet been fixed.
>
> So I believe there is a real possibility that another patch could
> re-introduce this bug.  If you had applied my patch as-is, that
> possibility would have been eliminated.  This is why I think my patch is
> better than yours.
>
> But I guess only time will tell who's right. :-)

You have a point with your variable usage "restriction", and Wolfgang has a 
point with the "readability" of your patch as it doesn't really tell what is 
fixed without read the current source. Could be that your implementation is 
the "better" one, but the patch Wolfgang applied was just less intrusive. 

> > And please accept my apologies thatt his was so complicated and  took
> > so  long.  [Nevertheless you still might want to try to find a way to
> > access the repository I  created  for  you  in  case  you  have  more
> > patches.]
>
> Stefan said he had a testing repo of some kind.  How about we just use
> that?  If Stefan is willing, he can apply my emailed patches to his repo.

No, we shouldn't "fork" the code here. Let's focus on the other open issues. 
You mention other bugs introduced by the libfdt code above. ;-)

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
=====================================================================