Native Code

Introduction

While KOS provides a great deal of infrastructure for developing smart dispense applications using Java and Chromium, there are use cases that these technologies are not well suited to solve. Whether porting an existing native application or integrating with custom hardware, sometimes native development is the best solution.

Development environment

A common challenge when developing native code for an embedded Linux board is establishing a development environment, particularly for Windows or Mac users. In some cases GNU tools can be installed locally but in the end the most common approach is to install the native toolchain on a development board and perform all development remotely in order to avoid configuring and building cross compilers and dealing with platform inconsistencies.

KOS facilitates native development by providing developer tools as an optional OS component that can be included in a vitual machine using KOS Studio. This allows developers to quickly configure a vm that will run locally but launch the full KOS stack including developer tools.

Hardware integration

Virtually every smart dispense device contains custom hardware that needs to be integrated into application logic and this is one of the most common native development tasks. Within KOS, native programs that integrate with custom hardware are called adapters and because these are so common, KOS provides libraries to make writing adapters easy.

One unique aspect of KOS is that it is designed from the ground up to make distributed architectures easy to build and adapters play a key role in this capability. All adapters connect to java via network socket which allows adapters to run on different boards than java is running on. This allows java to transparently work with hardware regardless of where it is located. For example, KOS ships with a USB adapter that detects when usb devices are added and removed from the system. This adapter also supports probing of usb-serial devices for pluggable hardware detection. In an architecture where there are two boards running KOS, perhaps only one runs java and chromium but both run adapters. Java will still be able to detect and interact with usb devices connected to either board just as if they were local.

Much of this is possible by using a KOS protocol called blink (short for Binary-Link). The blink protocol supports both command / response as well as events using a binary encoded payload. In most cases this allows native code to simply cast payloads to a structures and use the data directly as blink will guarantee memory alignment and even handle end-to-end endian differences.

Packaging and Delivery

KOS provides several mechanisms to package native code for installation and use on a smart dispense device:

OS layer: The underlying Linux os is constructed from multiple immutable disk image layers. If native code is required early in the boot process then it can be packaged as a layer.
KAB file: KAB files are the standard packaging mechanism for all KOS artifacts. Native code components can be packaged in a kab file and then mounted into the native filesystem by application logic. Once mounted, the contents of the kab appear as native files in the Linux filesystem and can be used just as if they were included in an OS layer but since the process is managed by application logic there is more overall control.