[U-Boot] [PATCH v2 3/3] image: Allow images to indicate they're loadable at any address

[Detlev Zundel]

Hello Wolfgang and Nicolas,

please allow me to barge in at that point.

As I strongly believe that we all want to advance our software in a
technical sense and not spend time in flame wars - I am trying to think
of ways forward from the current state of affairs.

Without evaluating all the arguments individually, let me pick up
Wolfgangs latest suggestion which indeed seems like a pragmatic way
forward:

> | I suggest the following:
> | 
> | - I will apply Stephen's previous patches to support relative images
> |   as they are useful for people who want to use "proper" uImages
> |   (containing a raw kernel image as payload) on different boards /
> |   architectures.
> | 
> | - If you want to boot zImages (with the kernel wrapper included and
> |   thus fully relocatable), then please feel free and submit patches to
> |   add support for booting zImage format in U-Boot.  Then you get what
> |   you want, and you can use zImages directly, without the 64 byte
> |   uImage header that is only hindering for your usage mode.
> | 
> | - It would be appreciated if we could get support for real uImages
> |   (wrapping a raw kernel image) into Linux, then.
> | 
> | This way those who want to use zImages can do so, and those who prefer
> | a different approach can have their ways, too.

My hope is that we can re-start the discussion from this - which
actually looks like a consensus.

For the unlikely but probable case of further disagreement, I propose a
vote on the mailing list as an "emergency tie breaker".  As we
previously did not need to resort to such a measure, we do not have a
formal procedure ready for such a thing.  Thinking about it a little
while, it would probably make sense to have people vote on the issue
that demonstrably care about the software and have invested substantial
effort in it.  A natural choice for such a set people are of course the
custodians.  So I would suggest to instantiate a poll among the
custodians as such a "tie breaker" if needed.

What do you think - is this a way forward?

Thanks
  Detlev

-- 
Perfecting oneself is as much unlearning as it is learning. 
                                        -- Edsger Dijkstra 
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de