[
https://issues.apache.org/jira/browse/MYNEWT-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins updated MYNEWT-534:
---------------------------------------
Fix Version/s: v1_0_0_rel
> 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)
