I dont have an answer but I would like to add something using the BLE stack as an example. The BLE stack wants to create tasks or a task and it wants the highest priority task. How do we let people know that the BLE stack must have the highest priority task? Through documentation? If we let people define task priorities there is a risk that they give the BLE task an incorrect priority. This would be an issue with either approach btw.
Anyway, I dont have a strong opinion either way. There are things I like and dislike about both approaches although I slight lean towards #1 as I am more familiar with it and it is a common way of doing things. Neither of which is sufficient justification for going with #1, of course :-). Will > On Nov 4, 2015, at 11:43 AM, Sterling Hughes <sterl...@apache.org> wrote: > > Howdy, > > I'm working on getting blinky a bit more developed as an initial > project. First part of that is getting console running on sim, which > I have working. > > One thing I've been looking at, is the hal_uart starts an OS task when > initialized. The priority of that task, and stack size is defined by > the MCU definition (e.g. hw/mcu/native, or hw/stm, etc.) > > I think task priorities are something that should be defined on a > per-project level. From what I can see, there are two options for > doing this: > > 1- Have the individual packages expect a #define from the project, in > the following format: > > hal_uart.c: > > os_task_init(OS_PRIO_UART, ..) > > project/blinky/include/project/os_cfg.h: > #define OS_PRIO_UART (10) > > This could be enforced using our capabilities concept, where the > package would req_capability: os_cfg, and the project would provide > that. > > 2- The init function could take the priority to start the task at. > So, when hal_uart_init_cbs() is called, it would take two additional > arguments the priority, and stack size. Anything that creates a task, > would be called directly from the project, with these arguments. > (uart code needs a little refactoring to make this easy, but should be > fine.) > > I'm leaning slightly towards option #2, as I don't like messing with > defines. That said, #1 is much more common, and they way that other > operating systems do it (I think, so that all priorities are defined > in a single header file, and you don't have to look through the code > to find them.) > > What do folks think? > > Sterling
