Re[2]: mmap()/read() and embedded systems.

Etienne Lorrain (lorrain@fb.sony.de)
Thu, 19 Mar 1998 14:30:54 +0001

Kenneth Albanowski wrote:
> Etienne Lorrain wrote:
> > Even if you have memory mapped flash as a file system in an
> > embedded environment, with romfs, the main problem is the
> > executable loader: it has to modify (resolve address) of the code
> > you are executing, so this code has to be copyed first in RAM.
> > I am not sure that using static library (instead of ELF) solves
> > completely this problem...
>
> It's unclear whether ELF will be useful for the uClinux project (it's
> relatively complicated, so we're currently using a custom -- and trivial
> binary format). In any case, it looks like we may be able to use a few
> trick to get located code (code that does not have to be PIC, since it is
> linked to the exact address in the target at which it will run.)
>
Considering the price of FLASH (compared to hard disk), it is not
a good solution to copy every library needed in every executable
software, mostly if you intend to run at least different tasks.

IHMO the best thing to do is to use for each library function a
calling way which do not need modification of the code of an
application by the loader. That is (a little bit like DOS/BIOS
interract) using an assembly instruction to jump at a constant
entry point, on different micro it is called software interrupt
(ARM, 8086), trap (68000), call door (80386)...

For some low level services (real time kernel) it will also disable
interrupts within library treatment if it is needed.
For Linux full system it will enable more mmap()/read()
or pages to copy on write by "mergemem".

You still need Position Independant Data if you intend to run
twice the same software (via virtual memory, maybe); how about
variable defined/unsed in library - I do not know.

What a long project !
Hope you will succeed.
Etienne.
----------- etienne.lorrain@ibm.net
-- hdc: irq timeout: status=0xd0 { Busy }
-- ide1: reset: success
----------> I like Linux !

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu