I think I prefer option two as well. If the priority is passed as an argument to the init function, it is easy for someone who isn't familiar with the code base to understand how priorities are determined. A project can still define all its priorities in a single header file, so that benefit is not lost.
Chris task priorities in a single fil On Wed, Nov 04, 2015 at 11:43:03AM -0800, Sterling Hughes 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
