Reducing RAM usage; why not buffer_alloc?

[dreamlayers]

I was wondering why recent versions of Rockbox use so much RAM even when running in ROM and so I examined the code.  I saw that firmware/common/unicode.c uses 64k for loading codepage files and I added ifdefs to disable loadable code pages.  I'm attaching a patch in case anyone is interested.  (I don't think it's worthy of being put in Flyspray.) I also disabled loadable languages and saved some RAM that way.  I'm not attaching a patch because what I did there is messy and not only about 20K is saved.

Then I thought of a better idea: instead of having  a preallocated array, allocate the memory with buffer_alloc the first time it is needed.  This way those who don't use a feature wouldn't have memory wasted by the feature.  This could be done for code pages, languages, fonts and perhaps more things.  (A loadable code page isn't used for ISO_8859_1 and UTF_8, english is built in and a font is built in.)  This technique is already used for buffers for the last.fm scrobbler and cue sheet functionality.  Is there any reason not to do this?

PS. .patch files are not accepted to I renamed it to .txt.  Then when I tried to post I was told I had posted already.  The error message due to the .patch attachment seemed to imply it wasn't posted and I can't find the post, so I'm posting again.  I hope this isn't a duplicate.

[Llorean]

Instead of simply attempting to bypass the restrictions set on the forums, in the future please ask rather than simply intentionally ignoring rules and limits.

[dreamlayers]

I see that .c and .h are permitted.  I could attach the whole .c file which I altered.  So, what is wrong with posting a patch file as an attachment?  

Is there any formal "forum rules" document which explains this?

[GodEater]

Patches go in FlySpray. Full stop. The End.

The Forum Guidelines, which you were supposed to have read, and agreed to when you signed up :

http://forums.rockbox.org/index.php?topic=5738.msg44378#msg44378

[dreamlayers]

Patches go in FlySpray. Full stop. The End.

Even if it's something I was experimenting with and not something I'd like eventually merged into the code?

[GodEater]

See the forum guidelines in my post above (just edited with link - sorry if you missed it.)

[linuxstb]

Is there any reason not to do this?

Yes - buffer_alloc can only be used at boot-time, so changing any of the settings you mentioned (font, language, code-page) would require a reboot in order for the setting to take effect.

There has been talk of removing that restriction - basically re-initialising Rockbox without a reboot, but afaik no-one has expressed an intention to do it.

[Lear]

There's a limited form of re-initialization, but only for the swcodec playback system (e.g., to allow changes to the crossfade settings).

To allow a full re-initialization would probably require a fairly big restructuring of how Rockbox is initialized and how the buffer allocations are made. But getting the buffer allocations done in the right order isn't trivial, and has been the source of more than one hard to find bug, so a cleanup in this area could be nice.

Note that any change to a buffer-related setting would then cause playback to stop, at least temporarily, and any music would need to be re-buffered. So there are drawbacks too.