POSIX pthreads and ARINC653 require support for creating threads/653 processes which do not have a static template, but fields are specified via the APIs at run-time. In addition, there is a customer desire to support dynamic thread templates for client server threads in RMA, where a field such as the scheduler name is desired to match the requesters.

Deos will not initially support using a user specified address as the stack address. For the FACE safety base profile, the thread creation attributes which must be supported are stack size and base priority. In the future for the safety extended profile, FIFO vs round robin scheduling policy, the size of the stack VAS gap, and support for pthread detached state will be needed.

The ARINC653 PROCESS_ATTRIBUTE_TYPE defines the attributes used when creating a 653 process. Stack size and base priority must be supported. The 653 library may depend on other kernel features for clocks/timers to support periods and deadlines, but they should not be needed at the thread template/attributes level.

The kernel will require the scheduler name to be part of the attributes. The 653/POSIX tooling must enable the libraries to construct the appropriate scheduler name based on other attributes such as affinity. In order to support RMA threads budget and slackEnabled could be supported, but mutex and ISR thread support may be limited to registry templates and createThread.

Proposal:
Create ThreadAttributes_t struct 
Add createThreadEx API similar to createThread where const char *templateName is replaced by const ThreadAttributes_t *threadAttributes. 
ThreadAttributes_t should use the forward compatible protocol to allow compatibility when extended.