An overview of the upcoming Oryx v0.2.0 release

With an upcoming Oryx Linux release on the horizon, it’s time bring you a few exciting updates! For one thing, we want to tell you about some of the features that distinguish Oryx from other OpenEmbedded based distributions, which make it a great starting place for IoT and embedded development. But, before we get to that? We’ve got an announcement to make and we’re a little excited about it.

Oryx Linux is now a project developed and supported by Togán Labs Ltd. (That’s pronounced toe-GAWN, if you’re not fluent in Irish!). Togán Labs are a new Irish start-up. They- we!- were started by three people- myself, Beth 'pidge' Flanagan, the former Yocto Project release engineer and a core OE developer, and Aoife FitzGibbon O’Riordan, our junior engineer.

What does this mean for you? For one thing, we’re now able to offer Oryx Linux support to our customers. We’ve got plans. Support plans! For more information on any of these, or custom embedded and IoT consulting services, contact our sales department at sales@toganlabs.com. And for more information on Togán Labs, head on over to our website http://www.toganlabs.com.

Now that that’s out of the way, let’s move on to an overview of some of the technical philosophies that have gone into Oryx Linux.

Lightweight Container Deployment

Oryx is primarily motivated by a desire to incorporate a lightweight Linux container implementation into the OpenEmbedded build system whilst maintaining the benefits of both systems. The key word here is 'lightweight': we're avoiding fully-integrated systems such as Docker which are targeted at cloud computing deployments rather than embedded deployments. Instead we're using runc, the lightweight container runtime which sits at the heart of Docker, without any of the surrounding tools such as containerd and Docker itself. This gives us the flexibility to address the needs of the embedded use-case.

One of the main aims of Oryx is to provide a developer workflow which is familiar to existing OpenEmbedded users. You should not be required to learn a new build system or method of creating images (such as Docker and its corresponding Dockerfile syntax) in order to incorporate the benefits of containers into an embedded Linux product. Keeping the focus on the OpenEmbedded workflow ensures that we retain all the benefits of this system, such as the excellent license compliance tooling, the extensible SDK and a proper cross-compilation environment. Other methods of creating container-based Linux systems are typically targeted at cloud computing deployments and don't address these issues that crop up when shipping an embedded Linux product. The benefits of Linux containers have been discussed at length elsewhere so we won't cover the general benefits here. However, it's worth mentioning the additional benefits that we get in the embedded world:

System and Application Profiles

To give the desired level of flexibility, Oryx adds two new concepts to the OpenEmbedded base system.

System Profiles

A system profile complements the OpenEmbedded machine selection and essentially specifies how the image we are building will be deployed onto the selected machine. Many platforms may be booted in multiple ways (local boot from flash memory vs remote boot via tftp for instance) and a system profile may be used to specify a boot mechanism. Additionally, an image may run under different virtualisation methods on a given platform and a system profile may be used to specify the chosen method. In each case the system profile will ensure that the correct build artefacts are produced to match how the image will be used. As system profiles are orthogonal to machine selection, consistent boot or virtualisation methods may be enforced across multiple platforms.

Two system profiles are provided in the initial Oryx release:

The system profile is determined by the ORYX_SYSTEM_PROFILE variable.

Application Profiles

An application profile specifies the use-case of a given image and typically corresponds to a particular software package or package group. The configurability here is greater than a traditional OpenEmbedded image recipe though, as the application profile may set PACKAGECONFIG values and other options to be applied to all components within an image. So it's possible to build a lightweight configuration of a library for one application profile but then enable additional options when building for a different application profile.

Here are two of the major application profiles provided in the initial Oryx release:

It's expected that Oryx will be enhanced by the addition of many more application profiles in future releases.

The application profile is determined by the ORYX_APPLICATION_PROFILE variable.

Image and Frame Recipes

The concept of an application profile effectively supersedes the OpenEmbedded concept of an image recipe. Therefore we only make use of one image recipe within Oryx and this is the oryx-image recipe. This recipe pulls in the packages needed by the chosen application and system profiles.

The oryx-image recipe also ensures that an extended os-release file is included in the image. This os-release file includes the usual information such as the distro name, version and home URL as well as Oryx-specific information such as the selected system profile, application profile and machine.

To simplify deployment of Oryx images we also have a top-level oryx-frame recipe. This recipe copies files specified by the chosen system profile from the OpenEmbedded deploy/images directory to a new deploy/oryx directory. This may seem trivial but it gives two benefits. As only those files required by the boot or installation method used with a given system profile are copied into the new directory, there is no clutter or confusion. Also, the deploy/oryx directory has sub-directories for the current version, selected system profile and selected application profile and this ensures that an image produced for one configuration is not accidentally overwritten by a subsequent build for a different configuration.

In normal usage, the top-level command to build an Oryx image will therefore be bitbake oryx-frame.

Developer Workflow

Developing a product which uses the Oryx distribution will typically involve two additional tasks beyond the usual OpenEmbedded workflow. However, these tasks should be fairly straightforward and future Oryx releases will introduce tooling to simplify and automate these tasks. These tasks are:

Future work within Oryx is expected to address the need for an update mechanism, both for the native rootfs image and for the individual guest images. This will likely involve the integration of an existing OTA update solution.

Summary

Hopefully this has been a useful overview of the ideas behind Oryx Linux. If you have any feedback or further questions please get in touch with us by email to support@toganlabs.com, or hang out with us on IRC in the #toganlabs channel on Freenode.