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 <email@example.com>. And for more information on Togán Labs, head on over to our website.
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:
* The ability to isolate applications requiring access to specialised hardware from those which just use ‘normal’ Linux interfaces such as the network and filesystems.
* The ability to mix legacy software which is dependent on specific older versions of system libraries with an up-to-date and secure base system. This is especially relevant in the embedded space where legacy applications abound.
* The ability to update and restart a full application stack cleanly and quickly by restarting a container guest instead of rebooting the whole device. For devices with long startup times there can be significant benefit here.
System and Application Profiles
To give the desired level of flexibility, Oryx adds two new concepts to the OpenEmbedded base system.
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:
* `native`: This profile indicates that the image will run “bare metal” on the chosen platform. Build artefacts suitable for writing to an SD card, USB stick or embedded flash memory are produced and are then compressed to save space. When possible, u-boot is enabled to provide greater boot-time flexibility.
* `guest`: This profile indicates that the image will run as a container guest under runc. No bootloader or kernel is compiled for this profile. Build artefacts are always compressed tar archives of a rootfs, ready for installation onto a host system.
The system profile is determined by the `ORYX_SYSTEM_PROFILE` variable.
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
* `full-cmdline`: The profile simply combines the OpenEmbedded full-cmdline package group with an SSH server.
* `host`: This profile includes runc and other tools needed to setup Linux containers. It provides a host environment for images built using the guest system profile described above.
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`.
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:
* Define application profiles for each new container image to be deployed onto a device. For example, you may wish to define an application profile consisting of device maintenance tools and an SSH server which will form the ‘maintenance’ interface to the device, along with an application profile consisting of a web application and server which will form the ‘user’ interface to the device. These images will all be built using the ‘guest’ system profile.
* Assemble the guest images built from the desired application profiles with a native rootfs built from the ‘host’ application profile into a final image ready for deployment to a device.
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.
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 <firstname.lastname@example.org>, or hang out with us on IRC in the #toganlabs channel on Freenode.
Togán Labs Ltd.