Bart Smaalders wrote: > Roland Mainz wrote: > > Adam Leventhal wrote: [snip] > > Quick look at the problem (kernel only): > > -- snip -- > > # scan all kernel files and dump all strings (or things which look like > > strings) > > $ cat $(find /kernel /usr/kernel /platform -type f) | strings -a | wc -c > > 15951405 > > # scan all kernel files for string-like stuff and remove duplicates > > $ cat $(find /kernel /usr/kernel /platform -type f) | strings -a | sort > > -u | wc -c > > 5342818 > > $ bc -l > > (15951405-5342818) / (1024 * 1024) > > 10.11713695526123046875 > > -- snip -- > > In theory we could save ~~10.1MB in the kernel (userland is likely much > > worse). > > > > Note that "strings -a" lists lots of garbage which isn't really strings > > which means the number will be below 10.1MB. Another limiting factor is > > that we cannot fold multiple string literals across module borders but I > > guess we can still save 3-5MB minimum. > > > > The number could be improved a little bit by adding a compiler option to > > fold all identical+duplicate read-only which will save some more memory. > > If you're going to do this sort of estimation, you need to be accurate.
Uhm... "estimations" will never be accurate (and I agree, my posting was some kind of inaccurate "milchmädchenrechnung" (=I don't know a matching english word for that)). > 1) don't count 32 and 64 binaries together The numbers are from my B51 VMware installation which is AFAIK 32bit-only (but I didn't check...). > 2) don't attempt to find strings in places where they cannot > be eliminated (eg don't pass -a to strings). ... and don't count the config files (which I forgot to eliminate) ... > On b60 32 bit binaries I get a potential savings of 886K - > a non-trivial amount of memory, but also a non-trivial amount > of work. [snip] Right... most of the work was already done by the "get OS/Net working with gcc"-project... in theory we could just add "-xstrconst" in the matching Makefiles... but the problem is that we cannot solve the problem of testing. I can do patches and test them via booting and running the machine and doing some development on it - but I lack the test suites to cover all possible codepaths which may (theoretically) be used, e.g. as long the testing requirement for such a patch is set to "must cover all codepaths" we won't make any progress in this area... ;-( ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
