[U-Boot-Users] U-boot refactoring

[U-Boot-Users] U-boot refactoring

[Grant Likely]

Between Jon's CFG->CONFIG changes, Sascha's u2boot effort, and the
duplicate file cleanup that I've been hacking on, there are a fair
number of invasive changes going in to u-boot.

Also, at OLS this year we talked a bit about formalizing the u-boot
release procedure and maybe using a merge window and a stabilization
period.

So, my question is this; with all the changes being talked about on
the list; what order/schedule should be used for bringing these
changes into mainline?  I think we should decide which pieces should
go in first, and plan to stagger them so there is time to recover from
each invasive change.  Thoughts?  I also think that Jon's CONFIG_
changes should probably be merged first, and as soon as possible.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] U-boot refactoring

[Wolfgang Denk]

Dear Grant,

in message <fa686aa40707031148x4e5508ebgac2268741ee98b2e@mail.gmail.com> you wrote:
> Between Jon's CFG->CONFIG changes, Sascha's u2boot effort, and the
> duplicate file cleanup that I've been hacking on, there are a fair
> number of invasive changes going in to u-boot.
> 
> Also, at OLS this year we talked a bit about formalizing the u-boot
> release procedure and maybe using a merge window and a stabilization
> period.
> 
> So, my question is this; with all the changes being talked about on
> the list; what order/schedule should be used for bringing these
> changes into mainline?  I think we should decide which pieces should
> go in first, and plan to stagger them so there is time to recover from
> each invasive change.  Thoughts?  I also think that Jon's CONFIG_
> changes should probably be merged first, and as soon as possible.

I still have to revocer from the pile of work that stacked up during
OLS, but I already managed to merge u-boot-testing today.

My plan is:

1) Create a branch and a custodian repo for U-Boot 2.x (note that I
   dislike both the names "U-Boot-NG" and "U2Boot"; not to mention
   legal issues when using branded names like "U2").

2) Come up with a description of design criteria  for  U-Boot  -  for
   both the old and the new one.

3) Officially announce the release cycle thingy.

4) Pull Jon's "cmdcfg" patch series into testing.

5) Pull Grant's relocation patch series into testing.

6) Pull as many "trivial" patches into testing as I manage to do.

...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Pain is a thing of the mind.  The mind can be controlled.
	-- Spock, "Operation -- Annihilate!" stardate 3287.2

[U-Boot-Users] U-boot refactoring

[Jon Loeliger]

So, like, the other day Wolfgang Denk mumbled:
> 
> I still have to revocer from the pile of work that stacked up during OLS,

You too? :-)

> but I already managed to merge u-boot-testing today.

Hooray!  Thanks!

> My plan is:
> 
> 1) Create a branch and a custodian repo for U-Boot 2.x (note that I
>    dislike both the names "U-Boot-NG" and "U2Boot"; not to mention
>    legal issues when using branded names like "U2").

Ugh.  I totally agree with WD here.

> 3) Officially announce the release cycle thingy.

Hey Grant -- Did _that_ sound official enough to you? :-)

> 4) Pull Jon's "cmdcfg" patch series into testing.

Pleas delay this a few days -- there's more brewing still, and
it would be best to get the next round completely, I think.


Thanks,
jdl

[U-Boot-Users] U-boot refactoring

[Wolfgang Denk]

Dear Jon,

in message <E1I5pmG-0007T0-4N@jdl.com> you wrote:
>
> > I still have to revocer from the pile of work that stacked up during OLS,
> 
> You too? :-)

Who? Me? No. Not really ;-)

> > but I already managed to merge u-boot-testing today.
> 
> Hooray!  Thanks!

You're welcome....

> > 3) Officially announce the release cycle thingy.
> 
> Hey Grant -- Did _that_ sound official enough to you? :-)

Not yet. There was no schedule attached with it yet :-)

> > 4) Pull Jon's "cmdcfg" patch series into testing.
> 
> Pleas delay this a few days -- there's more brewing still, and
> it would be best to get the next round completely, I think.

Ummm... I was really on the *verge* of doing this right now. But it's
your work, so you decide. Does that mean that I should  delete  these
patches from my stack ?

06/11 Jon Loeliger  [U-Boot-Users] [PATCH: cmdcfg: 00/19] Introduce initial versions of n
06/11 Jon Loeliger  [U-Boot-Users] [PATCH: cmdcfg: 01/19] Introduce initial versions of n
06/11 Jon Loeliger  [U-Boot-Users] [PATCH: cmdcfg: 02/19] common/cmd_[a-f]* : Augment CON
06/11 Jon Loeliger  [U-Boot-Users] [PATCH: cmdcfg: 03/19] common/cmd_[i-z]* : Augment CON
06/11 Jon Loeliger  [U-Boot-Users] [PATCH: cmdcfg: 04/19] common/ non-cmd: Augment CONFIG
06/11 Jon Loeliger  [U-Boot-Users] [PATCH: cmdcfg: 05/19] drivers/: Augment CONFIG_COMMAN
06/11 Jon Loeliger  [U-Boot-Users] [PATCH: cmdcfg: 06/19] fs/: Augment CONFIG_COMMANDS te
06/11 Jon Loeliger  [U-Boot-Users] [PATCH: cmdcfg: 07/19] disk/: Augment CONFIG_COMMANDS 
06/11 Jon Loeliger  [U-Boot-Users] [PATCH: cmdcfg: 08/19] net/: Augment CONFIG_COMMANDS t
06/11 Jon Loeliger  [U-Boot-Users] [PATCH: cmdcfg: 09/19] rtc/: Augment CONFIG_COMMANDS t
06/11 Jon Loeliger  [U-Boot-Users] [PATCH: cmdcfg: 10/19] lib_ppc/: Augment CONFIG_COMMAN
06/11 Jon Loeliger  [U-Boot-Users] [PATCH: cmdcfg: 11/19] lib_*/: Augment CONFIG_COMMANDS
06/11 Jon Loeliger  [U-Boot-Users] [PATCH: cmdcfg: 12/19] cpu/mpc*/ : Augment CONFIG_COMM
06/11 Jon Loeliger  [U-Boot-Users] [PATCH: cmdcfg: 13/19] cpu/ non-mpc*: Augment CONFIG_C
06/11 Jon Loeliger  [U-Boot-Users] [PATCH: cmdcfg: 14/19] board/[Ma-i]*: Augment CONFIG_C
06/11 Jon Loeliger  [U-Boot-Users] [PATCH: cmdcfg: 15/19] board/[k-z]*: Augment CONFIG_CO
06/11 Jon Loeliger  [U-Boot-Users] [PATCH: cmdcfg: 16/19] tools/ : Augment CONFIG_COMMAND
06/11 Jon Loeliger  [U-Boot-Users] [PATCH: cmdcfg: 17/19] include/ non-config: Augment CO
06/11 Jon Loeliger  [U-Boot-Users] [PATCH: cmdcfg: 18/19] README: Rewrite command line co
06/11 Jon Loeliger  [U-Boot-Users] [PATCH: cmdcfg: 19/19] configs/ mpc86xx: Rewrite comma


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The only person who always got his work done by Friday
                                                 was Robinson Crusoe.

[U-Boot-Users] U-boot refactoring

[Jon Loeliger]

So, like, the other day Wolfgang Denk mumbled:
> 
> > > 4) Pull Jon's "cmdcfg" patch series into testing.
> >=20
> > Pleas delay this a few days -- there's more brewing still, and
> > it would be best to get the next round completely, I think.
> 
> Ummm... I was really on the *verge* of doing this right now. But it's
> your work, so you decide. Does that mean that I should  delete  these
> patches from my stack ?
> 
> 06/11 Jon Loeliger  [U-Boot-Users] [PATCH: cmdcfg: 00/19] Introduce initi=
> al versions of n


Actually, if you are up for it now, please do so.  It would be good, I think.
But I am slowly working my way through the rest of the include/configs/*.h files
as well.  If you are OK with only some of them updated at a time, then we
should go for it.  I had sort of assumed you'd like to see all of the config
files updated at approximately the same time.  So, if you are willing to do
that step incrementally, go for it!

jdl

[U-Boot-Users] U-boot refactoring

[Wolfgang Denk]

Dear Jon,

in message <E1I5qQW-0007cq-3i@jdl.com> you wrote:
> 
> Actually, if you are up for it now, please do so.  It would be good, I think.

Me too, so I did it.

> But I am slowly working my way through the rest of the include/configs/*.h files
> as well.  If you are OK with only some of them updated at a time, then we
> should go for it.  I had sort of assumed you'd like to see all of the config
> files updated at approximately the same time.  So, if you are willing to do
> that step incrementally, go for it!

I think doing this incrementally now makes most sense. At  least  now
we have a common base again without a long stack of patches that need
to be maintained and adapted to other code changes that may (and did)
happen.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A good aphorism is too hard for the tooth of time, and  is  not  worn
away  by  all  the  centuries,  although  it serves as food for every
epoch.                                  - Friedrich Wilhelm Nietzsche
                          _Miscellaneous Maxims and Opinions_ no. 168

[U-Boot-Users] U-boot refactoring

[Robert Schwebel]

On Tue, Jul 03, 2007 at 11:04:18PM +0200, Wolfgang Denk wrote:
> 1) Create a branch and a custodian repo for U-Boot 2.x (note that I
>    dislike both the names "U-Boot-NG" and "U2Boot"; not to mention
>    legal issues when using branded names like "U2").

It was never meant as a project name, I'd prefer to see it being U-Boot
2.0.0 in the end.

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

[U-Boot-Users] U-boot refactoring

[Wolfgang Denk]

In message <20070704082032.GL25364@pengutronix.de> you wrote:
> On Tue, Jul 03, 2007 at 11:04:18PM +0200, Wolfgang Denk wrote:
> > 1) Create a branch and a custodian repo for U-Boot 2.x (note that I
> >    dislike both the names "U-Boot-NG" and "U2Boot"; not to mention
> >    legal issues when using branded names like "U2").
> 
> It was never meant as a project name, I'd prefer to see it being U-Boot
> 2.0.0 in the end.

Fine. The name of the custodian tree will be u-boot-v2, which goes in
the same line.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"It is better to have tried and failed than to have  failed  to  try,
but the result's the same."                           - Mike Dennison

[U-Boot-Users] U-boot refactoring

[Jon Loeliger]

So, like, the other day Wolfgang Denk mumbled:
> > Actually, if you are up for it now, please do so.  It would be good, I =
> think.
> 
> Me too, so I did it.

Excellent!  Thanks.

> I think doing this incrementally now makes most sense. At  least  now
> we have a common base again without a long stack of patches that need
> to be maintained and adapted to other code changes that may (and did)
> happen.

OK.  I'll merge and rebase my (next) patches on testing now!

jdl

[U-Boot-Users] U-boot refactoring

[Carsten Schlote]

Hi Grant,

> each invasive change.  Thoughts?  I also think that Jon's CONFIG_
> changes should probably be merged first, and as soon as possible.

Yes, these CFG_ defines are real show blockers. Getting rid of them in
all board headers could really simplify the integration of kconfig.

CFG_ defines can be everywhere else in the source, as long as they are
non defined or changed by a user. 

With all user-configurable defines starting with CONFIG_ we can start
with the rest :-)

Regards
  Carsten

[U-Boot-Users] U-boot refactoring

[Jon Loeliger]

On Wed, 2007-07-04 at 14:11, Carsten Schlote wrote:
> Hi Grant,
> 
> > each invasive change.  Thoughts?  I also think that Jon's CONFIG_
> > changes should probably be merged first, and as soon as possible.
> 
> Yes, these CFG_ defines are real show blockers. Getting rid of them in
> all board headers could really simplify the integration of kconfig.
> 
> CFG_ defines can be everywhere else in the source, as long as they are
> non defined or changed by a user. 
> 
> With all user-configurable defines starting with CONFIG_ we can start
> with the rest :-)


Say....  Not to put _too_ fine a spin on this, but there
is a _veeery_ similar issue brewing with the POST CFG_ symbols...

jdl

[U-Boot-Users] U-boot refactoring

[Wolfgang Denk]

In message <1183661913.26273.49.camel@ld0161-tx32> you wrote:
>
> Say....  Not to put _too_ fine a spin on this, but there
> is a _veeery_ similar issue brewing with the POST CFG_ symbols...

Let me know if you have specific ideas how  to  change  these;  we're
working  in  that  area right now (adding 440EPx POST support), so we
can do it better right from the start.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I will also, for an appropriate fee, certify that  your  keyboard  is
object-oriented,  and  that  the bits on your hard disk are template-
compatible.            - Jeffrey S. Haemer in <411akr$3ga@cygnus.com>

[U-Boot-Users] U-boot refactoring

[Jon Loeliger]

On Thu, 2007-07-05 at 15:09, Wolfgang Denk wrote:
> In message <1183661913.26273.49.camel@ld0161-tx32> you wrote:
> >
> > Say....  Not to put _too_ fine a spin on this, but there
> > is a _veeery_ similar issue brewing with the POST CFG_ symbols...
> 
> Let me know if you have specific ideas how  to  change  these;  we're
> working  in  that  area right now (adding 440EPx POST support), so we
> can do it better right from the start.

Ah, these have the same problem that the Command Line
selection has -- Bit fields are being used at compile
time to select code portions.  We'll need to introduce
symbols such as CONFIG_POST_x for each of the existing
CFG_POST_x symbols, and modify the users to have the
features conditionally compiled like #if defined(CONFIG_POST_x)
as well as modifying some (fewer!) board config files
to explicitly list which CONFIG_POST_x features are wanted.

Naturally, this can be done in a round after the Command
Line Config updates too!

jdl

[U-Boot-Users] U-boot refactoring

[Carsten Schlote]

Hi,

Am Donnerstag, den 05.07.2007, 13:58 -0500 schrieb Jon Loeliger:
> > With all user-configurable defines starting with CONFIG_ we can start
> > with the rest :-)
> 
> 
> Say....  Not to put _too_ fine a spin on this, but there
> is a _veeery_ similar issue brewing with the POST CFG_ symbols...

For my kconfig hack in the 1.x tree I to rework both the CONFIG_POST and
CONFIG_COMMAND stuff. Can be solved easily.

Carsten