Re: [ECOS] RE: eCos Loader

[Nick Garnett <nickg@ecoscentric.com>]

"Paul D. DeRocco" <pderocco@ix.netcom.com> writes:

> >
> > Instead the approach described by Tony would be more appropriate: the
> > application developer generates a table of just the symbols that he
> > expects his loaded modules to access. This way the main application
> > will be kept small.
> 
> This is an intrinsic problem with a loader: you have to create an OS that
> has an API suitable for loaded applications that haven't yet been written.
> In general, the most useful OS image would include symbol table entries for
> all documented functions in the included eCos subsystems. Otherwise you have
> to arbitrarily constrain the writers of loaded applications, and document
> those constraints. Yes, this means that the linked portion of the system may
> be larger than necessary for a particular app, but that's the only way to
> decouple the design of the OS from the design of the app.


The things being loaded will be application specific: device drivers,
video/audio codecs, protocol handlers, libraries etc. You just need to
define the API that they will use and build a symbol table to
match. There's no need to add stuff that they won't be calling.

> Typically, the only reference _into_ a loaded module is the start address.
> That is, the code is loaded, and a thread is started (or a function is
> called) at the module's start address.

That may be true in Linux, where the init routine then registers the
module into the OS data structures with function tables and the
like. This will also be the way that things like device drivers and
codec will work too. However, a more general library may have a
variety of interface calls.


-- 
Nick Garnett                                     eCos Kernel Architect
http://www.ecoscentric.com                The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss