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

Carsten Schlote c.schlote at konzeptpark.de
Tue Jun 19 18:37:20 CEST 2007


Hi,

> Please  be  careful  when  planning  for  this.  One  feature 
>  thatis essential  to  me is that it must be possible to have 
> all information for the configuration of a certain board in  
> a  single  configuration
> file   (i.   e.   something   corresponding   to   what  we  have  in
> include/config/<board>.h now)

That is exactly, what I have in mind. The current
include/config/<board>.h files will include the autogenerated autoconf.h
file (or better a tree of such files, so that build dependancies are
only triggered for those submodules whose configs have changed.)

Only those defines, which are unique for the target board will remain in
the include/config/<board>.h file.

> 
> >   This can be automated by a script and created lots of small files.
> 
> Again, be careful. Ther eis a lot of #ifdef and Makefile 
> trickery  in handling the CONFIG_ and CFG_ definitions, and 
> if you try to approach this  with  a script, then it will 
> *not* be a simple one. Also, "lots of small files" is 
> something that probably is not an improvement.

I fear, that the scripts can produces only templates for the Kconfig
files to reduce typing work. All the interactions and dependancies must
be added by hand later. Also the help stuff must be filled in by hand.
On the other hand, this has the advantage, that most sources are
reviewed and maybe rearranged, while the Kconfig files are worked out.
Of course the amount of Kconfig files should be reduced to a minimum.

With some careful planning, the Kconfig system can be setup in parallel
to the on-going work. The first step could be to have a working Kconfig
system which basically defines an empty menutree with nearly no options.
All target headers get patched to include these autogenerated headers.
<full regression test>. 

Now the most common defines will be moved from the headers to some
kconfig entry, e.g. the CONFIG_<boardname> define is a good candidate.
So more and more common defines will move into the config system. At the
end only the single use and board specific defines are left.

> Maybe there is a somewhat  less  perfect,  but  simpler  
> approach  to implement only a 90% or 95% solution with much 
> less effort?

Effort is relative :-) U-Boot is growing fast, and soon there might be
much more platforms. Linux and Busybox proof that a sophisticated config
system can scale with large projects - and any simpler solution might
lack this property and must be replaced later by some 'better' thing.
Then all work needs to be redone again. 

So I prefer the a 100% solution ;-)

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.267 from 19.06.2007
Virus news: www.antiviruslab.com





More information about the U-Boot mailing list