I know progress is a thing that cannot be stopped and change is sometimes
positive. But my preference is that we stick with the make file
configuration approach. It is small easy to add new configurations of
either boards or CPUs. What is more when starting out it is easy to follow
what is going on with a make file I maybe an old dog who doesn't like change
if it isn't broken why fix it?
In message <8D7C5F56B409554D9D46AC22195807F3061B3B at exchwenz01.dmcwave.co.nz> you wrote:
> I know progress is a thing that cannot be stopped and change is sometimes
> positive. But my preference is that we stick with the make file
> configuration approach. It is small easy to add new configurations of
> either boards or CPUs. What is more when starting out it is easy to follow
> what is going on with a make file I maybe an old dog who doesn't like change
> if it isn't broken why fix it?
Because U-Boot claims to be easily portable. And I can understand the
argument that a configuration menu that guides you through all the
questions might be useful.
One of my definitive requiterementes is that the Makefile approach
must not change significantly; only the way how we get a board
specific config header file will change.
Well, I don;t need such a change for myself - I'm probably much
faster to clone an existent port - we've done enough of them that I
will always find one close enough :-) But this does not mean I should
reject new ideas.
I still see technical issues; for example, I have not the slightest
idea how longish definitions like:
#define CONFIG_EXTRA_ENV_SETTINGS \
"key_cmd#=setenv addfb setenv bootargs \\$(bootargs) console=tty0\0" \
"key_cmd3=echo *** Entering Test Mode ***;" \
"setenv add_misc setenv bootargs \\$(bootargs) testmode\0" \
"nfsargs=setenv bootargs root=/dev/nfs rw nfsroot=$(serverip):$(rootpath)\0"
"ramargs=setenv bootargs root=/dev/ram rw\0" \
"addfb=setenv bootargs $(bootargs) console=ttyS1,$(baudrate)\0" \
"addip=setenv bootargs $(bootargs) " \
"add_wdt=setenv bootargs $(bootargs) $(wdt_args)\0" \
"flash_nfs=run nfsargs addip add_wdt addfb;" \
"bootm $(kernel_addr)\0" \
"flash_self=run ramargs addip add_wdt addfb;" \
"bootm $(kernel_addr) $(ramdisk_addr)\0" \
"net_nfs=tftp 100000 /tftpboot/pImage.lwmon;" \
"run nfsargs addip add_wdt addfb;bootm\0" \
"load=tftp 100000 /tftpboot/u-boot.bin\0" \
"update=protect off 1:0;era 1:0;cp.b 100000 40000000 $(filesize)\0" \
can be handled in a readable way, if at all. Things like that. Also,
I fear that adding new features will become much harder, as you'll
have to continually extend the config setup. And finally - has
anybody benchmarked the speed of such a new config scheme? Running a
MAKEALL over all PPC and ARM boards takes a considerable time already
now. I don't really want to add to build time...
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
See us @ electronica 2002 in Munich, Nov 12-15, Hall A3, Booth A3.325
> I still see technical issues; for example, I have not the slightest
> idea how longish definitions like:
Not at all. However, I have the feeling that they are not that common. Only
some board has this here and then.
But those long stuff could stay in the *.h file, if needed.
char "kernel environment settings"
and in include/config/special_board.h
#define CONFIG_EXTRA_ENV_SETTINGS \
"ten " \
"thousand " \
> I fear that adding new features will become much harder, as you'll
> have to continually extend the config setup.
For me it looks EASIER. A complete description of what is configurable is in
the config.in files. Right now, I have to do things like
grep '^#if' `find -name '*.c'` | sort | unique
to find out what is actually configurable. And then it's only slightly
documented, and dependencies are not laid out clearly.
> And finally - has
> anybody benchmarked the speed of such a new config scheme?
I doubt there is much difference... once you've run make
config|xconfig|oldconfig|menuconfig, you have to files. One is includeable by
"Makefile"s, the other one into C programs.
You simply include this and that's it. I can't see why this should slowdown
the compilation process.
One thing that might be a little time difference is the
cp board/<boardname>/def-configs .config
However, running "make oldconfig" on the current Bitkeeper tree of
www.openzaurus.org is negligible:
/usr/src/buildroot-oz# touch packages/config.in
/usr/src/buildroot-oz# touch .config
/usr/src/buildroot-oz# times make oldconfig
0.22user 0.09system 0:00.32elapsed 94%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (5351major+2500minor)pagefaults 0swaps
But then again the combined length of all config.in of this project is only
754 lines with now only 202 configurable variables (I have an 850 MHz AMD
with 1967 bogomips and the hard disk cache was "warm").
|Free forum by Nabble||Edit this page|