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



Rockbox mail archive

Subject: Re: Version 2.3

Re: Version 2.3

From: Greg Haerr <greg_at_censoft.com>
Date: Sun, 20 Apr 2003 08:40:27 -0700

> The plugins will have a size limitation, something like 20-32 kb, and only
one plugin will be loaded at any one time.

Why limit to one loaded plugin? Dynamic loading with several
modules could have other benefits, like allowing one of several
UI modules to load based on config, as well as also loading
normal plugins later. Another benefit, depending on loader
complexity, could be allowing module writers to know
less about the entire system, and instead focus on more
well-defined APIs (for instance, here a UI-function API
seperate from the UI would do well).

The MM could be simplified by running in slots or forcing
a LIFO unload order.


> The API will be in the form of a struct with function pointers that
Rockbox sends to the plugin after loading. The plugin will then use this
function pointer struct to call Rockbox internal functions, like this:
rockbox.lcd_clearscreen();

So what we need to get going here then is basically a discussion
of the module binary format and a small relocator? I presume
we want as simple as possible binary format (header, code,
reloc bits, symbols?). What about calling inbound, should
there be dynamic symbol linking, or just have a presumed
function table pointer inbound as well? If the latter, then
there probably ought to be a module signature per module
type to avoid loading code that will cause a system crash.

Regards,

Greg
Received on 2003-04-20

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