[MYNEWT-534] A cooperative package's "start event" might not get executed when OS started

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: v1_0_0_rel
• Security Level: Public (Viewable by anyone)
• Assignee: Christopher Collins
• Reporter: Christopher Collins
• Created: 03/Jan/17 20:17
• Updated: 09/Feb/17 03:06
• Resolved: 09/Feb/17 03:00

Description

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.

Issue Links

• is related to: MYNEWT-576 Update apps that use newtmgr framework to explicitly set the event queue with mgmt
• mentioned in: Page Loading...