All Data Structures Files Functions Variables Typedefs Enumerations Enumerator Macros Pages
System Definition .sdef

.sdef files can contain these sections:

App

An apps: section is used to declare one or more applications are to be deployed to the target system.

apps:
{
webserver
}

This will look for an application definition file called webserver.adef and include that application in the system.

In addition, the apps: section can be used to override limits and other settings for the application.

For example, to deploy a web server and limit its share of the CPU under heavy load to 500 (see CPU Share),

apps:
{
webServer
{
cpuShare: 500
}
}

Any of the following subsections can be used in a .sdef apps: section:

cpuShare
faultAction
groups
maxCoreDumpFileBytes
maxFileBytes
maxFileDescriptors
maxFileSystemBytes
maxLockedMemoryBytes
maxMemoryBytes
maxMQueueBytes
maxQueuedSignals
maxPriority
maxThreads
sandboxed
start
watchdogAction
watchdogTimeout

Use of one of these in the .sdef will override the .adef setting for all processes in that application.

Max Priority

Sets the maximum priority level the application is allowed to run threads at.

This acts as a ceiling. That is, it will not raise the priority level for any of the processes in the application. It will only lower the priority level if the application would have otherwise been allowed to use a higher priority.

For example, if a process in the application was configured in the .adef to start at high priority, and the .sdef section for that app has maxPriority set to "medium", then the process will start at medium priority. But, another process in the same .adef that is configured to start at low priority will still start at low priority.

apps:
{
foo
{
maxPriority: high
}
}

Bindings

This section contains a list of IPC “bindings”, which are essentially connections between applications’ external IPC interfaces (listed in the “requires” and “provides” sections of their .adef files). Each binding connects one client-side (required) interface to one server-side (provided) interface.

Interfaces are identified using the application name and the interface name, separated by a period (‘.’). The two bound-together interfaces are separated by an arrow ("->").

For example,

apps:
{
vavController
thermostat
airHandlerProxy
}
bindings:
{
// Connect the VAV controller to the thermostat
vavController.temp -> thermostat.temp
vavController.setpoint -> thermostat.setpoint
// Connect the VAV controller to the supply air duct temperature sensor
vavController.ductTemp -> ductTemperatureSensor.temp
// Hook up the VAV control outputs to the damper actuators.
vavController.supplyDamper -> supplyAirDamper.damper
vavController.returnDamper -> returnAirDamper.damper
// Use a network proxy to request duct temperature changes from the Air Handling Unit.
vavController.airHandler -> airHandlerProxy.airHandler
}

For security reasons, binding between applications is never performed unless explicitly specified in the .sdef or .adef files.

Beware that if an app's required interface instance is left unbound, the process or processes that require that interface may not be able to run.


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