Re: nmgr, shell vs ble host

[will sanfilippo <wi...@runtime.io>]

I am all for packages/libraries to have the ability to run from a single task and not have to create their own. Of course, we still must allow packages to create their own tasks and we need to make sure that these tasks run at a given priority. From what you are saying, that will still be allowed; you just want a way that a library/package that doesnt care about its own task to run within a single task context and have the OS provide for this.

It seems to me that creating an “application task” to handle this is easy enough to do. Any library/package that does not need its own task would “register” with this task (or library or package or whatever you want to call it) and there you go. The only “tricky” thing is the following: say the project/app you are building consists only of packages that use their own task and create it themselves and dont want to run in anyone else’s context. This means there is no need for this “app” task. Maybe I am looking at this the wrong way or missing something (quite likely) but how would that app task not get created in that case?

Will

PS RE: controller task. While a lot of the critical timing done by the controller occurs at interrupt context or is performed by the chip, a fair amount of work is done at the Link Layer task and I dont think it is advisable to move it all into interrupt context. I know you would love to get rid of the controller stack but I would not advise it. Doing “upper” link layer functions within the context of another task seems fraught with peril. If the LL task gets delayed by just a few msecs we could be missing connection and/or advertising events. Which while not catastrophic is not advisable.

And just an FYI: maybe this is simply how I have been doing these things for the last many years, but I prefer extremely short interrupts. Currently, there are what I consider very long interrupts and the only reason is so that we did not need two controller tasks: one for the timing critical LL functions and one for the not so timing critical LL functions. And that was just to save stack! :-)

> On Aug 31, 2016, at 4:17 PM, Sterling Hughes <st...@apache.org> wrote:
> 
> PS: I’d be interested in what Will has to say w.r.t controller, which may be an exception — given that it will have hard timing requirements, and likely need to be a high priority task.  My mail was meant to address more “appy” (app-ish?) libraries.
> 
> On 31 Aug 2016, at 16:14, Sterling Hughes wrote:
> 
>> Hey,
>> 
>> I’ve been wondering how we should handle libraries in the OS, that need to run in a task context, but don’t necessarily need their own _dedicated_ task context.
>> 
>> I think right now we have two approaches:
>> 
>> - Create a library that takes an event queue, and expects to be called within a task context, but doesn’t create it’s own task (example: BLE host - http://mynewt.apache.org/latest/network/ble/ini_stack/ble_parent_ini/)
>> 
>> - Including that package creates its own task, and requires it to operate in that context.  (example: newtmgr - https://github.com/apache/incubator-mynewt-core/blob/master/libs/newtmgr/src/newtmgr.c#L504)
>> 
>> Personally, I think we should move the first approach taken by the bluetooth host for all system libraries that require a task context to operate.  I don’t see any reason why you couldn’t run newtmgr and BLE host in the same context, and save the RAM space by having a big app task that keeps posting to its own event queue.
>> 
>> What do folks think?  I think while we’re revising system init, it would be a good time to look at this, and come up with a consistent mode of operation.
>> 
>> Sterling