[PATCH 1/3] mtd-utils: new memory wrappers

[Mike Frysinger]

On Thu, Sep 30, 2010 at 02:01, Artem Bityutskiy wrote:
> On Thu, 2010-09-30 at 01:59 -0400, Mike Frysinger wrote:
>> On Thu, Sep 30, 2010 at 01:48, Artem Bityutskiy wrote:
>> > On Thu, 2010-09-30 at 01:15 -0400, Mike Frysinger wrote:
>> >> as i'm sure you noticed, i didnt make these up.  i simply moved them
>> >> from existing mtd-utils code.
>> >
>> > Actually no, I did not notice!
>>
>> np ... only one or two utils uses this, and easy enough to convert
>> them.  before i go further though, a question on direction ...
>>
>> mkfs.jffs2 has a lot of helpers that can be moved to common.h.  but it
>> implements things using C functions & va_args.  the common.h header
>> takes the CPP approach of expanding the variable args.  which way to
>> go to ultimately unify the code base !?
>
> I have not strong opinion, how about creating common.c ?

issues (not good or bad, but just are):
 - change "#define PROGRAM_NAME" to "const char program_name[]"
 - errors thrown up by libraries would be flagged as part of the
program, and not part of the library (i.e. libubifs)
 - unused functions would take up space in final exe

the first is easy to change.  the 2nd i think is OK (and maybe even
less confusing for the user when reviewing error output).  the 3rd i'd
like to make sure we address.

two possible solutions to 3rd one.  one ugly but portable, one nice
but gnu-specific.  although we already use gnu-specific code and
flags, so maybe that isnt an issue (no one has complained yet).

ugly: create lib/common/ and put every function into its own file and
merge into libmtd.a.  linker only pulls in objects (funcs) when
needed.
nice: use -ffunction-sections -fdata-sections -Wl,--gc-sections.
additional advantage of saving space across all linked in library code
and not just common.h stuff.
-mike