Simon Wood writes:
>
>
> > I am still trying to dowload the code, but the server seems to be a bit
> > slow. Have you built some kind of loader, or are you running the kernel as
> > a binary as you mentioned last week?
> >
> [<Simon Wood>]
> It's still runs as an application (and doesn't relocate itself), you will
> need to reboot (while(1) in main.c).
>
> Once the I've sorted out memory placement, it can relocate and the memory
> manager can be got going. The psion holds the stack in the same segment as
> the data (I believe this is the same on all 8086's), what size stack does
> the kernel require? and where do the application's stacks go?
Each task has a kernel stack stored in its task entry which is 1024 bytes.
The user space stack are a bit messy at the moment. When a chunk of memory
is allocated for a process data segment the stack is placed at the top
of this area of memory so it grows down towards the top of the heap which
grows up. This unfortunatly means that each task has to have all the memory
it ever needs all the time. Solution have been sugested to this but they
all involve restricting the stacks freedom to grow.
>
> > Do you mean that we should have a directory under elks/arch, or do you
> > mean
> > a whole new distribution tree? I think a whole new distribution tree would
> > be excessive, and would mean that the psion port would not benefit as
> > easily from bug fixes in the rest of the code. An arch/psion directory is
> > justified I think though.
> [<Simon Wood>]
> Sorry for not being clear, I meant an elks/arch/psion tree... I think this
> will require a little rework of the existing master Makefile to get it
> working well with both.
>
The top level Makefiel doesn't really do everything right anyhow. Feel free
to change it so that the kernel Image for the architecture is built in the
arch dir.
Al
