Rockbox mail archive

• Next message: Mark Bright: "Re: Version 2.3"
• Previous message: Björn Stenberg: "Re: Version 2.3"
• In reply to: Greg Haerr: "Re: Version 2.3"
• Next in thread: Jos Laake: "Re: Version 2.3"
• Reply: Jos Laake: "Re: Version 2.3"
• Reply: Greg Haerr: "Re: Version 2.3"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Greg Haerr wrote:
> Why limit to one loaded plugin?

Because we still don't want to have a dynamic memory allocation (and code relocation) system. All plugins will be compiled and linked for a hard coded position in ram.

> Dynamic loading with several
> modules could have other benefits, like allowing one of several
> UI modules to load based on config,

This is still possible, although only one plugin will be loaded at any one time. Since plugins intended to be "UI grabbing" functions, it also makes little point having two of them loaded at one. Why have both Sokoban and Tetris in memory, for instance?

> I presume
> we want as simple as possible binary format (header, code,
> reloc bits, symbols?).

Even simpler, I want no relocation at all. At least in the first versions.

> What about calling inbound, should
> there be dynamic symbol linking, or just have a presumed
> function table pointer inbound as well?

My current plan is to have a single inbound call, which passes the function pointer struct and then is used by the plugin as the execution thread. When that call exits, the plugin is unloaded and control returns to the core Rockbox GUI.

-- 
Björn

• Next message: Mark Bright: "Re: Version 2.3"
• Previous message: Björn Stenberg: "Re: Version 2.3"
• In reply to: Greg Haerr: "Re: Version 2.3"
• Next in thread: Jos Laake: "Re: Version 2.3"
• Reply: Jos Laake: "Re: Version 2.3"
• Reply: Greg Haerr: "Re: Version 2.3"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]