[
https://issues.apache.org/jira/browse/MYNEWT-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins updated MYNEWT-534:
---------------------------------------
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.
was:
*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.
> 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
>
> *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.4#6332)
