Overview
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
- environment variables that can be used inside the .sdef file and .adef, .cdef, and .mdef files
- directories to search for interface files (e.g., .api files)
- programs that should be made available as command-line tools on the target device
.mdef Files
Kernel Module Definition .mdef files are used to declare kernel modules to be bundled with Legato and installed on the target system. Each kernel module has a
.mdef file that specifies the path to the pre-built kernel module binary file, and lists module parameters to be passed to the module's
insmod
command.
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 cpuShare and maxFileBytes limits.
Copyright (C) Sierra Wireless Inc. Use of this work is subject to license.