Open nashif opened 8 years ago
by Benjamin Walsh:
FYI: the tasks/users stories for this are tracked internally at WR since we're doing at least the initial push for this. If/when needed, we can transition them to the public Jira. I've added Al so that he can handle this if needed during my vacation.
by Benjamin Walsh:
RFC available here:
https://gerrit.zephyrproject.org/r/#/c/2255/2/incoming/unified_kernel.rst
and discussed on the devel mailing list.
by Benjamin Walsh:
Extra info from porting Feature from WR's internal tracking:
DESCRIPTION
As a Zephyr user (i.e. an application developer using Zephyr or an RTOS developer modifying Zephyr) I don't want to deal with the kernel's layered Microkernel and Nanokernel model, as it makes the kernel difficult to understand and can increase development overhead.
This feature merges the Microkernel and Nanokernel into a single Kernel entity. Where feasible, duplicated services are combined and undesirable service gaps are filled. These changes are made transparent to users by providing "legacy API" versions of any API made obsolete by the unified kernel.
DOCUMENTATION
RATIONALE
ACCEPTANCE CRITERIA
Blocks GH-544
Reported by Gajinder Vij:
As a Zephyr developer, I would like a unified and more complete kernel API with optimized performance, so that I don't have to choose between the nanokernel or the microkernel when developing applications.
The Zephyr dual-kernel model is confusing for some, and is somewhat harder to use than traditional cookie-cutter RTOS kernels by even experienced developers. Also, while the nanokernel performances for both footprint and speed of execution (context-switch time, latency, etc.), the microkernel could be improved on both fronts.
Problems
Proposed Improvements:
(Imported from Jira ZEP-334)