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