[U-Boot-Users] Some questions about what is planned toimproveU-Boot configuration...

[Carsten Schlote]

Hallo,

> No, this is NOT what I mean. "include" means that the 
> information  is distributed  over  at  least  two  files, one 
> of them auto-generated, which makes things just worse.

Maybe we talking about the same thing. All information should be
configured with a 
Single frontend, and the data is saved into a single file. And from this
single file
a single header might be created (autoconf.h) or for improving the
rebuild behaviour this
File might be post processed and split into separate files. So each
subsystem just includes
Related defines, and only subsystems with changed config must be
recompiled. 

The last thing is just a nice feature to save compile time, but it's
still a single config file as a source.

The new config system will make all these board headers obsolete and
replaces them by default configs for each supported target.

That's my goal with the new config system. 

> The whole default configuration is unique for a board.

Yes, and for each board a <boardname>_defconfig will reside in
include/configs. The former <boardname>.h file can be deleted, as all
information from this file is now auto-configured from the defconfig
file.

> That was what I wanted to point out. Your previous posting 
> sounded as if you expect a few lines of grep and sed trickery 
> would do  all  the work ;-)

No, way :-) This will become some nice handwork. Maybe some people will
help a bit. See it positive, I get a chance to cross-read most of the
current sources to figure out meaning and dependencies of defines. This
will for sure help me for future U-Boot ports.

> That "<full regression test>" is actually the fun part :-(

Yes, it means to have 100dreds of toolchains at hands and maybe a
computer cluster at hands :-) But this issue can be discussed when we
are ready for such test.

> I don't. I'm an engineer. I always try to recognize where it 
> makese sense to stop. See below.

Sure. This is my every-days life as well. But when the current config
system reaches ist limits, it might be much more work to do the
necessary step.

Or the project will split into smaller or new projects to reduce
complexity. I would prefer to have a single bootloader project available
for all existing targets - so I can benefit from the common parts and
features everywhere. 

I still remember the times where we had different bootloaders for all
and everything. I don't want that back.

Regards
  Carsten





____________
Virus checked by G DATA AntiVirusKit
Version: AVKA 17.248 from 15.06.2007
____________
Virus checked by G DATA AntiVirus
Version: AVKB 17.268 from 20.06.2007
Virus news: www.antiviruslab.com