-
Notifications
You must be signed in to change notification settings - Fork 6.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unified Kernel #1893
Comments
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-2144 |
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
- Non-intuitive nature of the nanokernel/microkernel split
- Double-context switch affecting kernel performance (speed and footprint)
- Duplication of object types between the nanokernel and microkernel
- System initialization running in the idle task
Proposed Improvements:
- Make the nanokernel 'pre-emptible thread' aware
- Unify fibers and tasks as one type of threads by dropping the Microkernel server
- Allow cooperative threads to operate on all types of objects
- Clarify duplicated object types
- Create a new, more streamlined API, without any loss of functionality
(Imported from Jira ZEP-334)
The text was updated successfully, but these errors were encountered: