Posix SDK

Makefile

The SDK makefile provides targets for building the STRIDE Runtime library and two executable applications - a strideDaemon and installApp test app (for running the STRIDE installation tests).

The default make target builds just the STRIDE Runtime library. To build the strideDaemon executable, specify the daemon make target. Similarly, to build the installation test application, specify the installtest make target.

Configuration

The behavior of the makefile can be affected by setting certain make variable parameters. For example, the following make invocation will change the value of the TARGET and DEBUG variables when making:

 make TARGET=arm DEBUG=1

The following variable are intended to be specified or overridden as needed:

TARGET

The default compiler toolchain when TARGET is set to i138 is gcc/g++/ar, which are assumed to be in your path. For any other TARGET value, the toolchain tools are $(TARGET)-linux-gcc/g++/ar where $(TARGET) is replaced by the specified TARGET setting. If your toolchain does not fit this pattern, you will need to modify the makefile directly.

LIBRARYTYPE

The default behavior of the makefile is to build the STRIDE Runtime as a static library. If you prefer a shared library, set this value to '.so'.

DEBUG

The default configuration compiles with optimization and NDEBUG defined. If you prefer debuggable binaries, set this value to 1.

Target API (stride.h)

The Linux SDK provides a simplified application interface for initializing the STRIDE subsystem and starting STRIDE messaging and IM threads. The API includes the following routines:

srBOOL strideInit(const strideIO_t * io)

This function initializes the STRIDE subsystem. The IO configuration is passed in as an argument. If this argument is NULL, then the process will attempt to attach to an already running runtime application (daemon) using shared memory for IPC. THis function should only be called once per application.

srBOOL strideUninit(void)

Terminates any threads that have been started with this API and uninitializes the STRIDE subsystem.

srBOOL strideCreateThread(strideThreadFunc_t entry, const srCHAR * name)

Creates a thread to be managed by the STRIDE subsystem. Threads created using this routine will be sent a palSTOP_EVENT notification (available from palWait) and should respond promptly to this event. The name parameter is used primarily for logging purposes.

strideCreateIMThread(name)

This is a macro that wraps the invocation of strideCreateThread for intercept module entry point functions. Only the IM name must be provided.

void strideWaitForExit(void)

This function can be called by the main application thread to block until a termination signal is received. Internally it uses the pause function to wait for signals to be delivered and then checks if termination has occurred.

void strideExDaemonize(const srCHAR* lockFile, const srCHAR* runAs)

This function is called by applications to deamonize the process. Both arguments are optional. The first argument specifies a lockfile path/name to use to insure that only one instance of the process is running. The second argument specifies a username to run as (setuid)

This is functional is optional - if you prefer to run your application as an interactive console application, do not call this function. If you are running as a daemon, we strongly recommend that you have the PAL_LOG_TO_SYSLOG macro defined (in palcfg.h) so that PAL log messages will be sent to the syslog (this is default setting currently).

Target Integration

Here are a few examples of how to integrate the stride API into your application.

Note: the following code assumes that the intercept module was generated with a name of myintercept. Change all references to that name in your code to the chosen intercept module name.

Standalone Application Integration

The following code demonstrates how to integrate your application with the STRIDE Runtime. Your application might require other logic at startup - you can integrate the following calls according to your needs. Note that this code initializes the STRIDE subsystem and assumes a single standalone process that creates the STRIDE system threads as well as application threads. The call to palDeamonize is optional here - remove it if you don't want you application to run as a daemon.

 #include <stdlib.h>
 #include <unistd.h>
 #include <stride.h>
 #include <myinterceptIMEntry.h>

 int main(int argc, char **argv)
 {
     strideExDaemonize(NULL, NULL);
     strideIO_t io = {strideDEFAULT};
     if (strideInit(&io) != srTRUE)
         return -1;

     if (strideCreateIMThread(myintercept) != srTRUE)
         return -1;

     strideExWaitForExit();
     strideUninit();
     return 0;   
 }

Multiprocess Application Integration

This code demonstrates how to integrate your application with the STRIDE Runtime in multiprocess mode. The only difference with the preceeding sample is the call to strideInit which, in this case, specifies no IO parameters which indicates to the API that the communication and runtime threads should not be started. In order for the host to communicate with this application process, the strideDaemon (or other STRIDE IO enabled process) will need to running simultaneously. As before, the call to palDeamonize is optional here - remove it if you don't want you application to run as a daemon.

 #include <stdlib.h>
 #include <unistd.h>
 #include <stride.h>
 #include <myinterceptIMEntry.h>

 int main(int argc, char **argv)
 {
     strideExDaemonize(NULL, NULL);
     if (strideInit(NULL) != srTRUE)
         return -1;

     if (strideCreateIMThread(myintercept) != srTRUE)
         return -1;

     strideExWaitForExit();
     strideUninit();
     return 0;   
 }