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: elf loader

elf loader

From: Marcin Bukat <marcin.bukat_at_gmail.com>
Date: Fri, 26 Oct 2012 22:27:39 +0200

Hello rockboxers!

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/
What can it bring good for rockbox:
- It removes the need for overlays. If plugin load fails in pluginbuf
due to lack of ram, audiobuf is grabbed and plugin is loaded there.
This is transparent and properly coded plugin doesn't need to know
where it is loaded.
- 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)
- It is the first step to move some functionality from the core to the
loaded on demand plugins (core plugins?)
- Maybe even dynamicaly sized pluginbuf and codecbuf

What is the cost:
- size impact https://docs.google.com/spreadsheet/ccc?key=0Ah1OY3AHjewUdERVRkt4SHhPUjJiOXF0SjMwd2hzaVE
  Loader binsize is in rockbox.* and is actual binsize increase.
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

TODOs/others:
If this change would be integrated into mainline code it implies a few things:
- SH and MIPS toolchains are too old to support this reliably and need updating.
- It is questionable if this is desired thing for SH. This targets are
very limited both in binsize allowed and in ram. If someone move some
parts of the core to the loaded on demand core plugins (like database
for example) it may still be beneficial. New toolchain with -flto and
-Os will more or less counterbalance elfloader size. It is technically
possible to use old scheme for SH and elfloader for others but it is a
bit of work to properly ifdef code, makefiles and linker scripts.

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
SH?

cheers,
Marcin Bukat (wodz)
Received on 2012-10-26

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