Skip to content
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

Closed
44 of 49 tasks
zephyrbot opened this issue May 13, 2016 · 4 comments
Closed
44 of 49 tasks

Unified Kernel #1893

zephyrbot opened this issue May 13, 2016 · 4 comments
Assignees
Labels
area: Kernel Feature A planned feature with a milestone priority: high High impact/importance bug

Comments

@zephyrbot
Copy link
Collaborator

zephyrbot commented May 13, 2016

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)

@zephyrbot
Copy link
Collaborator Author

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.

@zephyrbot
Copy link
Collaborator Author

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.

@zephyrbot
Copy link
Collaborator Author

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

  1. Update public Zephyr project documentation to describe new unified kernel APIs, and to mark obsolete APIs as deprecated.
  2. Update public Zephyr project documentation to remove references to nanokernel & microkernel layers.

RATIONALE

  1. A unified kernel is easier for users to understand, and provides a unified approach that eliminates some existing restrictions of the kernel. This makes Zephyr more likely to meet the expectations of experienced RTOS developers.
  2. A unified kernel is easier for Wind River developers (and others) to support and extend. It eliminates the need for duplication of effort when supporting both Microkernel and Nanokernel configurations.
  3. A unified kernel provides significant opportunities for both footprint and performance improvements, particularly in Microkernel configurations.
  4. Potential customers/partners could potentially merge all of their development into Zephyr. Easier to do with a well-known model.

ACCEPTANCE CRITERIA

  1. All user stories accepted.
  2. All test cases passed.
  3. Before/After comparison of benchmark test cases on Galileo Gen 2

@zephyrbot
Copy link
Collaborator Author

zephyrbot commented Sep 16, 2016

Blocks GH-2144

@zephyrbot zephyrbot added priority: high High impact/importance bug area: Kernel Feature A planned feature with a milestone labels Sep 23, 2017
@nashif nashif closed this as completed Feb 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Kernel Feature A planned feature with a milestone priority: high High impact/importance bug
Projects
None yet
Development

No branches or pull requests

3 participants