Personally, I keep wanting to try and have the OS start up right away. 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… :-) > On Dec 10, 2016, at 4:04 PM, Sterling Hughes <sterl...@apache.org> wrote: > > Hi Chris, > > On 10 Dec 2016, at 13:37, Christopher Collins wrote: > >> Darn, you're right. I'm writing these emails from my phone, and I didn't >> look at the code closely enough. For other packages, the start event >> only gets executed the first time the event queue gets used (as you >> said). I guess it has worked out in practice because the application >> uses the package shortly after the OS starts. >> > > Yeah, that’s what I noticed too. :-) > > For now, it’s OK, I can just call my init from main() after the default event > queue is set. > >> That's not so great. Second stage initialization sounds good to me. >> Alternatively, the system could keep track of packages that need an >> event queue, and enqueue their start event when a default event queue is >> set. Earlier, we discussed using linker sections to accomplish this >> without requiring any RAM. I looked into this, but concluded it wasn't >> possible without modifying the linker scripts. >> > > I think we should probably use this opportunity to (again) review system > initialization, which is fast becoming our most circularly discussed topic > :-) I’d throw in there whether or not to initialize components in the idle > task (using up stack), and making sure that we map sysinit stages to the > driver initialization stages as well. > > As far as a proposal, what do you think of having 2 initialization stages: > > - Before OS > - After OS > > And we can break each stage into primary, secondary and tertiary order, so, > in terms of number space we have: > > - 0: first init order, before OS > - 1: second init order, before OS > - 2: third init order, before OS > - 3: first init order, after OS > - 4: second init order, after OS > - 5: third init order, after OS > > I think we probably need to modify the package system configuration to > specify both stage & order, e.g. > > pkg.init_func_startup.name: XX > pkg.init_func_startup.order: 0 > pkg.init_func_kernel.name: YY > pkg.init_func_kernel.order: 1 > > This should allow us to hook in at either of these stages. > > I also think we probably need to give meaning to at least the primary and > secondary init orders here, e.g. designate which services are available after > each of these functions and come up with some documented nomenclature for it. > > Sterling >
