If you’re using a product with an embedded device or an IoT gateway, there’s a good chance it’s running the Zephyr* operating system. In fact, we hear about new products and prototypes using Zephyr every day, and there are probably many more that we’re not even aware of.
At the Embedded Open Source Summit earlier this year, Anas Nashif, the chair of the Zephyr Technical Steering Committee, shared how Zephyr became one of the most active open source projects available today and what’s next for the project. Watch his talk, 9 Years in the Making, the Story of Zephyr, Starting with Commit Nr. 1.
Introduction to Zephyr
Zephyr is a real-time operating system (RTOS), designed for resource-constrained systems, including embedded environmental sensors, LED wearables, and sophisticated smart watches. The project was started in 2014 and was publicly launched as a Linux Foundation project in 2016 with founding members Intel, Wind River, Synopsis, and NXP. The project goals were twofold:
- Create an open source solution for embedded controllers that would be adopted by silicon vendors and the embedded community.
- Become a sustainable open ecosystem governed by the community while providing value to firmware developers running on different instruction set architectures (ISAs).
With most silicon vendors adopting Zephyr—and an ever-increasing and vibrant community—it’s safe to say Zephyr has achieved its goals. In fact, Google ranked Zephyr as one of the most critical open source projects today because of its strong community growth and wide adoption rate.
By all metrics, Zephyr is widely adopted, attracting more than 1,600 project contributors and spanning 13 supported architectures.
Bird’s-eye view: How we got here
Launching an open source project like Zephyr requires a lot of preparation, such as garnering support, finding contributors, and picking the right name and license. As Zephyr gained traction after its public launch in 2016, contributors added their ideas and helped evolve the project by improving the user experience, changing build systems, introducing new ways to manage vendor modules, and enabling support for more architectures. All of this culminated in LTS1, the first long-term support (LTS) release, on which many members started basing products.
Major milestones and features have been added over the years, and work is still being done every day to continue to scale Zephyr.
While the project’s first official commit was in April 2015, the first code started with an even earlier commit through a collaboration with Wind River based on VxMicro* in late 2014. Interestingly, this code was not a new concept, but had already been running as an RTOS on some products. This code is production-level quality and is still running on some Intel® laptops.
The first lines of code came from Wind River in 2014
Early stages: Getting ready for launch
Between the first announcement at an internal Intel event in late 2014 and the official launch in early 2016, the project racked up about 7,000 commits. On top of that, the first commit in the Zephyr tree was 2,200 commits squashed into a single commit. These commits accomplished a lot of work in the first year before release, including:
- Generally cleaning up the code to prepare for public release, such as checking patches and polishing up the code style
- Overhauling the proprietary custom build system to a Linux*-style Kbuild
- Introducing a Linux-inspired device model
- Removing custom features that couldn’t be released to the open source world, many of which would be added back later, such as the user space
- Adding support for launch hardware and implementing the first APIs and drivers; for instance, we supported four boards at launch: Arduino* 101, generic ARM* boards like NXP* FRDM-K64f, Arduino Due, and the Intel® Galileo Board
Though many of these components have since transformed in some way, the central functionality was in place from beginning. Through hardware abstraction, Zephyr enables you to write an application and seamlessly scale it across architectures and vendors with minimal changes. This has always been the selling point of Zephyr, and it represents where Intel wants to take embedded controllers in the future.
License considerations
Another consideration in the early days was choosing the right license. Zephyr was originally BSD licensed, but we switched to Apache* License 2.0 per the request of early partners. Apache is not compatible with GPLv2, and as people are increasingly using Zephyr with existing hardware on Linux, it’s a problem we have to deal with all the time.
Midstages: Developing an RTOS for everyone
We underwent many changes during the time from the public release to the LTS1 release. Here’s a summary:
- Build system: After a while, we discovered Kbuild didn’t work well with Windows*, so we changed the build system again to CMake* to help expand our user base.
- Networking: Zephyr supported IoT and Bluetooth* Low Energy (BLE)‒based devices from the beginning. During this period, we added a Nordic* Bluetooth controller and moved from the Contiki* stack to a native implementation.
- Review system: We moved from Gerrit* to GitHub*.
- Continuous integration (CI): We changed CI providers from Shippable* to GitHub Actions.
Moving to the unified kernel
One of the biggest transitions we made during this era was moving from a dual-kernel model, which used nanokernels and microkernels, to the unified kernel. In a dual-kernel model, the nanokernel runs cooperative threads called fibers, and the microkernel runs preemptive threads called tasks. While this design worked for certain use cases, it was unintuitive and inefficient.
To make it easier to use the RTOS with more use cases, we introduced the concept of the unified kernel. Dropping the microkernel altogether, unified kernels combine fibers and tasks into one type of thread. This allows cooperative threads to operate on all type of objects, removing the need to duplicate object types between the nanokernel and microkernel. All of this was accomplished with the creation of a new API that simplifies threads without losing any functionality.
Replacing the dual-kernel model (pictured to the right), the unified kernel simplifies threads without impacting functionality.
From LTS1 to now: Maturing into a self-sustaining ecosystem
Since the release of the first LTS in 2019, Zephyr’s story has been all about becoming widely adopted, being implemented into more products, and growing into a self-sustaining ecosystem. A good measure of our growth is in the evolution of architecture support. When we launched, Zephyr supported four small boards you could fit in your pocket. Now Zephyr supports large-scale deployments, such as wind turbines that provide power to millions of people and many other projects.
In fact, people don’t even associate the project with Intel anymore, as they did early on, because we started the project and many of the supported boards were Intel® products. Now the project is in the hands of the community. That’s the goal any open source project should want to achieve.
Shortly after we launched in 2016, collaboration spiked and the community started driving the project.
This sort of collaboration means that things get done faster. If you need a feature or would like Zephyr to support new hardware, anyone can submit a request and the community is empowered to implement it for you. We even see customers asking their software vendors to extend support to Zephyr.
Zephyr’s ecosystem opens the door to more collaboration opportunities and faster feature implementation.
Looking to the future
Zephyr and the embedded open source community are picking up momentum, and we’re just getting started. In addition to encouraging community involvement and growing our user base, we plan to continue to aggressively pursue project safety and security goals and improve the user and developer experience, including easing migration between releases and maintaining a stable and rich API. We also plan to release the third LTS next year.
About the presenter
Anas Nashif, Principal Software Engineer, Intel
Anas Nashif is a principal software engineer at Intel. He is the upstream maintainer of various Zephyr subsystems and areas and the chair of the Zephyr Technical Steering Committee. Anas has been involved with Zephyr since 2015.