Hi Wolfgang,
On Mon, Feb 18, 2013 at 3:35 AM, Wolfgang Denk wd@denx.de wrote:
Dear Tom,
In message 51216721.1010603@ti.com you wrote:
There's another thread I don't have yet (and I don't have this one in gmail yet even). But, I am OK with custodians using their repos, but not the master branch, for unrelated but otherwise good patches. I'm also fine with patchwork bundles. I suppose we could use the staging repository for these changes instead.
What I mostly object about there is that these patches would go into mainline basicly unreviewed, as patch submission and pull request is all done from a single person, with no other feedback on the patches at all. And this affects a lot of common code...
Actually, I see this change when pulling u-boot-x86.git/master:
-> bloat-o-meter u-boot-before u-boot
What board is this please?
Some specific notes here - I think it boils down to moving crc32 into the hash framework. This adds some overhead, but has a few benefits.
add/remove: 9/0 grow/shrink: 3/14 up/down: 1006/-560 (446) function old new delta hash_command - 424 +424
This is the generic hashing command. What is happening here is that the crc32 command is getting a few more features, more like sha1sum. However, this might not be desriable - and in fact this patch changes the behaviour of the CRC storage and verify to support using an environment variable, and requiring * before the argument when an address is required! That needs to be fixed, at least.
The intent is to try to unify the hashing/crc features into a single framework. If you enable only crc32 and nothing else then this has quite a cost (0.5KB at present). I think I can reduce this code by making the full features of hash.c only available when something more than just crc32 is enabled. However, it might involve some #ifdefs...
strncasecmp - 156 +156 simple_itoa - 104 +104 crc32_wd_buf - 76 +76 setenv_hex - 68 +68 setenv_ulong - 52 +52 strcasecmp - 36 +36 do_mem_loopw 304 328 +24 static.local - 22 +22 do_mem_loop 268 288 +20 hash_algo - 16 +16 do_mem_cmp 332 340 +8 do_mem_mw 224 220 -4 set_working_fdt_addr 72 52 -20 load_serial_ymodem 300 280 -20 load_serial 512 492 -20 index_partitions 200 180 -20 do_load_serial_bin 1844 1824 -20 do_load 468 448 -20 do_jffs2_fsload 320 300 -20 do_imgextract 636 592 -44 NetLoop 832 788 -44 do_mem_cp 312 252 -60 do_bootm 1244 1180 -64 do_mem_crc 188 88 -100 do_mem_mtest 1436 1332 -104
So there are changes all over the place, including a growth of the memory footprint. I think this needs at least minimal review.
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@denx.de Time is an illusion perpetrated by the manufacturers of space.