On Mon, Apr 18, 2016 at 09:43:35AM -0700, Christopher Collins wrote:
> On Mon, Apr 18, 2016 at 09:18:16AM -0700, will sanfilippo wrote:
> > For #2, my only “concerns” (if you could call them such) are:
> > * Using OS_EVENT_TIMER as opposed to some other event. Should all
> > OS_EVENT_TIMER events be caused by a timer? Probably no big deal… What
> > events are going to be processed here? Do you envision many host
> > events?
>
> Yes, I agree. I think a more appropriate event type would be
> OS_EVENT_CALLBACK or similar. I am a bit leery about adding a new OS
> event type for this case, because it would require all applications to
> handle an extra event type without any practical benefit. Perhaps
> mynewt could relieve this burden with an "os_handle_event()" function
> which processes these generic events. My concern there is that
> applications may want to add special handling for certain event types,
> so they wouldn't want to call the helper function anyway.
>
> The OS events that the host would generate are:
> * Incoming ACL data packets.
> * Incoming HCI events.
> * Expired timers.
(I meant "process", not "generate"!)
Oops... I went down a rabbit hole and forgot to address the main point
:). What we would *really* want here is something like:
* BLE_HS_EVENT_ACL_DATA_IN
* BLE_HS_EVENT_HCI_EVENT_IN
However, the issue here is that the event type IDs are defined in a
single "number-space". If the host package reserves IDs for its own
events, then no other packages can use those IDs for its own events
without a conflict. The 8-bit ID space is divided into two parts:
0 - 63: Core event types (TIMER, MQUEUE_DATA, etc.)
64+: Per-task event types.
So, the options for the host package are:
1. Reserve new core event IDs. This avoids conflicts, but permanently
uses up a limited resource.
2. Use arbitrary per-task event IDs. This has the potential for
conflicts, and doesn't strike me as a particularly good solution.
3. Use a separate host task. This allows the host use IDs in the per-task
ID space without the risk of conflict.
4. Leverage existing core events. This is what I proposed. It avoids
conflicts and doesn't require any new event IDs, but it does feel a
bit hacky to use the TIMER event ID for something that isn't a timer.
I think this might be a common problem for other packages in the future.
I don't think it is that unusual for a package to not create its own
task, but still have the need to generate OS events. So perhaps we
should think about how to solve this general problem.
Chris
