|
Rockbox mail archiveSubject: Re: Version 2.3Re: 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 |