> On Dec 11, 2016, at 11:21 AM, Sterling Hughes <sterl...@apache.org> wrote: > > Hi, > >> >>> On Dec 11, 2016, at 10:55 AM, Christopher Collins <ccoll...@apache.org> >>> 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. >>> > > +1
I agree. If there are too many options here, it becomes even harder to understand. Preferably we should keep this stuff simple, making the barrier of entry to development lower. > >>>> 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? >>> > > I’m not crazy about malloc()’ing this space. Especially since system init > (where we’d use this memory) is where people malloc() their memory pools, and > so you have 1K of space that could potentially affect memory exhaustion. > Maybe its an awful idea… but why not let people specify the startup task > stack, and we can guarantee that this task gets deleted before the rest of > the tasks/system runs. That way, you can just choose one of your task’s > stacks that is sufficiently large, and use that for startup stack. > Most of the malloc()’s for packages happen when they’re initialized. And having malloc()’d init stack present during this step will have effect on this. And freeing the stack right after will automatically lead to heap fragmentation. And we’d need some new, mandatory, architecture specific code which switches stacks for a task while the task is running. While not complex, it is yet another thing to write/debug when adding a new architecture. However, I like the idea of app assigning a startup task, and then executing sysinit() in that task’s context.
