Alan Cox writes:
>
> > I know that the code sized is fixed when an application is compiled, as is
> > the initialised and un-initilised data.
> > This gives us minimum code and data segment sizes.
>
> Yes
>
> > We also need a stack, and maybe some heap space:-
> > Where does this go and how is it allocated?
>
> Linux 8086 takes a very simple approach. It uses the minix (and PC/IX) trick
> of setting the maximum heap size at startup time. Thats not vital, you could
> put the stack at the base of the data segment and allow the BSS to grow
> upwards (still a fixed stack limit). You would then need to call the kernel
> for a BSS extend (sbrk - already exists notionally) and may need to shuffle
> big chunks of memory around to find a new place for it.
>
> Thats probably a better model than the current minix one.
>
> > Psion (on SIBO) seem to place a fixed stack at the bottom of the data
> > segment (which grows down towards DS:0000), then initialised data, then
> > un-initilised and then heap (which grows up). This has the advantage that
>
> Psion were a bit more clued up here than Minix
>
> > the 'hardware protection' can detect if the application writes outside it's
> > allocated data segment and halt the application. But the disadvantage that
> > the maximum stack size MUST be allocated at compile time.
>
> That goes anyway
>
> > Could this approach be taken with ELKS or do we need a resizable stack?
>
> This would be a big improvement for ELKS, but one you would want to make
> soon if we do it because it means recompiling the entirity of user space
> and tweaking the linker.
>
I am seriously considering adding this to the kernel, but I am not clear
why the linker needs to be tweaked. Surely the linker just deals with the
data and bss segments, and leaves the stack and heap to be sorted out at
load time?
Al
