I guess, for no really great reason, I thought it would be weird to malloc, say, 1024 bytes, then free, say, 960 bytes. No weirder than what I was suggesting. :-) I guess there a number of things we could do here: malloc a temporary stack and free that whole thing and either do another malloc or change the task stack information to a bss defined idle task stack.
I did leave out the fact that we would need to modify the stack information in the task structure. I cannot recall exactly the information we keep in the task structure for the stack but this would not be hard to do; we would just need to do it. Will > On Dec 11, 2016, at 10:55 AM, Christopher Collins <[email protected]> wrote: > > 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
