> And the benefit of doing like this would be... ?
>
> The ability to allocate different sized blocks of memory based on total
> size or config values.

Yes, but using your suggested approach we would need to reboot in order to
use new config values. I'd hate something like that. Would be like Windows. I
would vote against such a system introduced in Rockbox.

> You have to allocate your buffers now, don't you?

If declaring a static buffer means allocate to you, then yes.

> The statement was made that dynamic allocation was too complicated .

Yes. Too complicated for what we get. We already have a malloc()
implementation so its not the absense of code that has lead to this decision.

> That is only true if you also implement release and reuse of memory. If you
> only allow for dynamically sized allocation from the total memory pool,
> without realloc() or free() type functions, then it does not have to be
> difficult at all.

It isn't difficult, it is complicated and needs lots of code.

But by all means, when you're done writing your patch, please post it and
allow the rest of us to try it out and review it.

The subject of malloc and memory usage gets this big attention every time it
is brought up on this list, and we always get a huge bunch of suggestions
from people. But so far *none* has provided any source code to prove their
points.