Legato definition files are used as input to the Build tools mksys, mkapp, mkcomp, and mkexe (known collectively as the mk tools). The definition files, together with API Files, make it easier to develop component-based software, automatically generating a lot of boiler-plate code.

Interfaces are defined using .api files. Implementations of those interfaces are constructed as reusable components. Components can be combined into apps. Apps can be installed and run on target devices and integrated into systems of inter-communicating applications deployed together to target devices in a single step.

All def files use a Common File Format.

.adef Files

Application definition .adef files are used to specify the external interfaces and internal content of applications that can be built, installed, and run on target devices.

.adef files can also be used to override some settings of components without having to change those components themselves, thereby making the components more reusable.

Each application has a .adef file that describes:

which executables should be built from which components
additional files from the build system to be included in the app
processes to be started (by running what executables with what command-line arguments and environment variables) when the app starts
if the app should automatically start when the target device boots
files (or other file system objects) from the target root file system to be available to the app at runtime
limits on the app at runtime (e.g., cpu limits, memory limits, etc.)
overrides for memory pool sizes and configuration settings for components in the app (future)
IPC bindings between components within the app
IPC interfaces made visible to other apps

.cdef Files

Component definition .cdef files are used to specify the external interfaces and internal content of reusable software components.

Each component has a single Component.cdef file that defines:

source code files used to build the component
files from the build system to be included in any app that includes the component
files on the target to be accessible to any app that includes the component
IPC interfaces the component implements
other components needed by this component
memory pool sizes
configuration settings for the component (future)

.sdef Files

System definition .sdef files are used to interconnect applications with each other and with the target's runtime environment (e.g., hardware devices).

.sdef files can also override some app settings.

An .sdef file defines a system of one or more applications that can be deployed to target devices in the field. Each .sdef file lists:

apps are to be installed on the device
IPC connections permitted between apps
overrides for limits, configuration settings, and IPC bindings within apps

Build Tool Search Paths

Two are used:

source search path - lists file system directories where the build tools look for source code files and components.
interface search path - lists file system directories where the build tools look for interface definition files (.h files and .api files).

The default search path “.” is the current working directory where the build tool ran.

Search paths can be changed through mk tools command-line options:

'-s' sets the source search path
‘-i’ sets the interface search path

$ mksys packageTracker.sdef -i ~/work/interfaces -s ~/work/components

Precedence and Overriding

Settings in a .sdef file override settings from both the .adef and Component.cdef, while the .adef overrides settings in the Component.cdef. This increases reusability by allowing an integrator to override a component's or app's settings without having to change that component or app.

Most configuration settings can be overridden on the target device at runtime (although, some won't take effect until the app is restarted).

Unsandboxed App Limits

Although it's better for apps to be sandboxed, apps aren't limited to running inside a sandbox. We call these unsandboxed apps.

Even though unsanboxed apps aren't constrained the same way sandboxed apps are constrained, the Supervisor will still enforce CPU Share and Max File Bytes limits.

Copyright (C) Sierra Wireless Inc. Use of this work is subject to license.