Read-write configuration data

[Chris Johns]

Mick Davis wrote:
>
> Hopefully RTEMS will get an elf loader in the future and this will be
> true more generally.
>

Sorry, I missed this bit of your post.

RTEMS is getting a loader based around the standard dlopen/dlcose family 
of calls. The project is here ...

  http://git.rtems.org/chrisj/rtl.git/
  http://git.rtems.org/chrisj/rtl-host.git/

Some doco in need of updating is ....

  http://www.rtems.org/ftp/pub/rtems/people/chrisj/rtl/rtems-rtl.html

The first git repo is the target side code which is an ELF loader and 
link editor. It loads relocatable object files locating the code 
anywhere in memory. A global symbol table allows access to any listed 
global symbols including the base kernel image. Object files can be 
separate ELF object files or in a library archive file, ie libc.a. You 
can load dependent object files, ie load object files with unresolved 
externals that are resolved by each other, and the unresolved symbols 
will be automatically resolved. There is a custom memory allocator that 
allows fine grain control over all aspects of memory allocation 
including read+write and read access control.

The second repo is a host based linker for RTEMS to build applications. 
It will take your application object files and resolve the symbols to 
determine the object file set you need to load. It will create an 
application "package" or a script type file listing the object files to 
load.

The project is at the point of implementing an RTEMS application 
"package". This is the file format an RTEMS application uses. The 
current thinking is an LZ77 compressed library archive (see fastlz.org). 
The application loader will itself just be a small application that uses 
the dlopen API. You can develop custom loading solutions that work at 
the object or library level.

The load is not large how-ever it is not intended for tiny RTEMS 
applications.

Chris