ELKS executable, time for a change?

[Harry Kalogirou <harkal@gmx.net>]

Hi all,

 Lately I desided that the fact that processes come with a fixed data
segment, is quite restrictive. So I tried to solve that. I studied the
work that Al did on this before and came to the conclution that indeed
the only memory setup that will allow us to expand the data segment is
this (from the Documentation/text/bin-formats.txt) :

+-----------------+------------+----------------+
|    | <--- stack | data + bss |  heap ---> |   | < current->t_endseg
+-----------------+------------+----------------+
^                        ^                  ^
0x0            current->t_enddata        current->t_endbrk

This is mainly because bcc assumes ds == ss. So we can't move the stack
at the end of the data segment everytime sys_brk() instructs us to
enlarge it.

It is obvious that with this setup we will have a freely expandable
heap, while the stack will be fixed. So :

1) We need the linker to define the stack space at compile time.
2) Since ds==ss, the linker whould create executable with the data
segment pointers offseted by the stack size.

As Al says in the bin-formats.txt file, we can use the -D linker option 
to give the data offset. The main problem now if that we can't tell if
and how much offset an executable has, or equaly what stack the
executable needs.

We probably need to change the linker to produce a new executable
format, a custom format for ELKS. What are your thoughts on this?

Also I would like to ask Al if he can explain how was he planning to
support an enlarging stack? This is mentioned in mm/malloc.c. I
personaly don't see a way for this to happen. Am I missing something?

Harry