On Sun, Dec 11, 2016 at 10:11:44AM -0800, will sanfilippo wrote:
> Personally, I keep wanting to try and have the OS start up right away.

I wonder if this could solve the problem that Sterling raised (no
default event queue during sysinit).  The control flow in main() might
look like this:

1. Start OS
2. Create and designate default event queue.
3. sysinit()

I think it would be nice if we could avoid adding another initialization
stage.

> There are definitely “issues” with this:
> a) We do not want to waste idle task stack.
> b) When tasks are started they would start running right away. This
> might cause issues where a task does something to a piece of memory
> that another task initializes, but since that other task has not
> initialized it yet…
> 
> b) can be avoided by locking the scheduler until initializations are finished.
> 
> a) is problematic :-) I think someone brought this up before, but I
> wonder if it is worth the effort to do something “a bit crazy” like
> the following: the idle task uses “the heap” during intialization.
> Once initializations are over (or at some point that we determine),
> the idle task stack is made smaller and the “top” of the heap is set
> to the end of the idle task stack. For example, idle task stack is at
> 0x20008000 and is of size 1K bytes; the bottom of the heap is at
> 0x20007000; the top of the heap is at 0x20007C00 (in my nomenclature,
> heap allocations start from the bottom). At some point, the top of the
> heap is moved to 0x20007F80.
> 
> Yeah, maybe a bit crazy… :-)

I don't think that's too crazy.  It would be great if we could just
malloc() a temporary stack, and then free it when initialization
completes.  I guess the worry is that this will cause heap
fragmentation?

Chris

Reply via email to