[ https://issues.apache.org/jira/browse/MYNEWT-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christopher Collins resolved MYNEWT-534. ---------------------------------------- Resolution: Fixed > A cooperative package's "start event" might not get executed when OS started > ---------------------------------------------------------------------------- > > Key: MYNEWT-534 > URL: https://issues.apache.org/jira/browse/MYNEWT-534 > Project: Mynewt > Issue Type: Bug > Reporter: Christopher Collins > Assignee: Christopher Collins > Fix For: v1_0_0_rel > > > *Vocabulary for this ticket:* > +Cooperative package:+ A package which uses an eventq to do work, but which > doesn't have its own task. Such a package is told which eventq / task to use > at runtime, or it just uses the eventq designated as the default. > +Start event:+ An OS event that a package needs to execute as soon as the OS > starts. Such an event generally "kicks off" the package. Example: the BLE > host's start event initiates communication with the controller. > -- > *Problem Description:* > The problem concerns cooperative packages which aren't explicitly told which > event queue to use, i.e., a package which uses the default event queue. This > type of package only enqueues its start event when it tries to enqueue a > second event. For some packages, this is not noticible, because the > application calls into the package's API on start up, kicking off the start > event. In other cases, the package is meant to do things on its own with no > interaction from the app (example: mgmt/newtmgr). These packages are broken > unless the app explicitly specifies an eventq for them to use. > The reason for the odd behavior is that a package doesn't know which eventq > it will be used when it first gets initialized. If the app explicitly > assigns an eventq to a package, the package is able to enqueue its start > event at that time, evading this problem. Packages which use the default > event queue never get an opportunity to enqueue their start event because the > default queue may not be designated when the package is initialized. > Furthermore, enqueueing to the default event queue would be premature, as the > app may set the pacakge's event queue shortly afterwards. > -- > *Possible solutions:* > 1. Require the app to designate the default event queue before calling > sysinit(). When a cooperative package is initialized, it immediately > enqueues its start event onto the default event queue. If a package's event > queue is then explicitly set, the start event is removed from the default > queue and placed on the specified queue. > Problems with this approach are: it places some odd restrictions on how the > main() function should look. Creating an event queue and designating it as > the default prior to calling sysinit() probably won't look right. > 2. Cooperative packages register themselves at init-time. When the OS is > started, all registered packages enqueue their start event on the assigned > queue (or default if none assigned). > The downside of this approach is that it requires extra ram to hold the > registration list, and a small amount of code to call the registration > function in each pacakge's init function. > 3. Place all start events in a special linker section. When the OS is > started, each event in the linker section is enqueued. This approach doesn't > require any extra RAM. > Problems with this approach: linker scripts must be modified to be made aware > of the new linker section. Also, a package's event doesn't get included in > the final binary if none of the package's symbols are referenced by name. An > example of such a package is newtmgr; this package starts itself, and is then > accessed indirectly through function pointers. -- This message was sent by Atlassian JIRA (v6.3.15#6346)