Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide
translations



Rockbox mail archive

Subject: Re: Port of Mini-XML library to Rockbox: making progress.

Re: Port of Mini-XML library to Rockbox: making progress.

From: Daniel Weck <daniel.weck_at_gmail.com>
Date: Fri, 14 Sep 2007 13:03:57 +0100

On 14 Sep 2007, at 12:37, Daniel Stenberg wrote:
> On Fri, 14 Sep 2007, Daniel Weck wrote:
>
>> The cause is probably the underlying memory management logic
>> (simulated dynamic memory allocation, currently borrowed from the
>> Doom plugin). I am working on this and would be happy to get some
>> help.
>
> How much and complicated malloc do you need?

malloc, realloc, calloc and free are used a lot in the current port
(well in fact, their Doom-borrowed couterparts are used: Z_Malloc,
etc.).

The main XML tree parsing algorithm does not seem to use recursion,
so that makes the memory handling logic easier to code. There's
basically a sort of linked-list to hold the tree structure, and by
using the SAX-like parsing model we can discard nodes on the fly
(thus the need to free space dynamically in the globally-allocated
memory buffer).

> It might be time to drag in a complete malloc implementation to the
> pluginlib so that all the plugins that want it could use it. It
> would probably make sense compared to the current situation with a
> large amount of half-baked implementations spread out all over...

Agreed.

> I may be a bit biased here, but one alternative for use is dbestfit:
> http://daniel.haxx.se/projects/dbestfit/
> http://sourceforge.net/projects/dbestfit/

Thanks, I'll take a look.

> (I'm not proposing malloc for the kernel or core Rockbox, only for
> plugins that in fact already do this but in a less "controlled"
> manner.)

My main worry is that ultimately, I want to be able to control audio
playback from the plugin, in addition to managing my own memory
buffer for the timing graph of the DAISY presentation. There clearly
seem to be a conflict if my plugin steals get_audio_buffer() from the
core playback module.

Anyway, first things first: XML parsing ! ;)

By the way, my latest code now crashes at the same place in both the
simulator and the Gigabeat, which will make debugging a lot quicker !
No more USB (plug,unplug)+ :-)

Cheers, Dan.
Received on 2007-09-14

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy