Rockbox mail archiveSubject: Re: elf loader
Re: elf loader
From: Amaury Pouly <amaury.pouly_at_gmail.com>
Date: Sat, 27 Oct 2012 20:26:20 +0200
I've been working for some time on elf loader for codecs and plugins.
> Currently it is in Proof-of-concept stage. Latest snapshot is
> available here: http://gerrit.rockbox.org/r/#/c/326/
Awesome job !
> - It removes the need for overlays. If plugin load fails in pluginbuf...
Always a good thing in my opinion.
> - It opens possibility to have multiple plugins loaded at the same time.
> - It opens the possibility to unify codecbuf and pluginbuf and
> moreover share iram between codecs and plugins (well this is more
> theoretical one as codecs usually utilize pretty much iram)
+1, this could definitely lead to some simplification
> - It is the first step to move some functionality from the core to the
> loaded on demand plugins (core plugins?)
might be interesting in the future (usb drivers ? database ?)
> - Maybe even dynamicaly sized pluginbuf and codecbuf
> What is the cost:
> - size impact
> Loader binsize is in rockbox.* and is actual binsize increase.
The increase is pretty small, it shouldn't be a problem in most targets.
> Plugins and codecs increased size is *on disk*. When loaded to the
> memory they have the same requirements as in current master.
- increased code load time, although it is fast enough that I don't
> see the difference
> - added complexity
That was expected, these days we have lots of space so the increase on disk
size is not a problem as long as the load time is fine. In my opinion the
real added complexity is the linker tricks to actual produce the files.
> Before I move forward I would like to hear Your opinion about all
> this. Do you see inclusion of such loader beneficial? What to do with
I'm definitely in favor of its inclusion, after some more tests of course.
If it is not too hard, I would vote for keeping both systems with a
configure switch to select so that SH for example can be kept as it is.
Received on 2012-10-27