SSI Tutorial 1079003.11

System Services Interface (SSI)
Training
1079003 1.1 © 2000 Trillium Digital Systems, Inc. All rights reserved.
Confidential and Proprietary 1
Purpose
This self-paced tutorial is a detailed introduction to the
System Services Interface and the common
functionality shared among the various flavors of SSI.
This tutorial is supplemented by other presentations that

detail the various flavors of SSI and by the SSI FAQs
available through the Customer Service Website.
This tutorial should be read only after the Trillium

Advanced Portability Architecture (TAPA) WBT
module has been fully studied and understood.
Goal
Through this training presentation, customers
familiarize themselves with the common architectural
features and functionality of the System Services
Interface.
By understanding how the System Services Interface
isolates Trillium software products from the
underlying operating system, the customer can fully
integrate and customize their software, and thus
begin the larger task of addressing application
development considerations.
Objectives
By the end of this presentation you will be able to:
• Define what the System Services Interface is, give an

overview of its functionality, and define key concepts
and terms.
• Describe the architecture of the System Services
Interface, and how it isolates Trillium’s portable layer
software from the underlying operating system.
• Differentiate between the different flavors of System
Services and understand the functionality of each.
Agenda
Terms
System Services
Flavors of System Services
Terms
TAPA Task Message

System Task Message Priority
Permanent Task Message Route
Driver Task STREAMS Messages
Memory Trillium Messages
Memory Models Post Structure
– Static Memory Post Structure Elements
– Dynamic Memory
TAPA Task
• A TAPA Task is an invocation of a Trillium layer
• Identified by entity, instance, and processor IDs:
– An entity ID functionally distinguishes between
Trillium products.
– An instance ID distinguishes between multiple
instances of the same entity. Although an instance
ID is one of the parameters that identifies the task,
multiple instances of the task may not be
supported in an actual implementation.
– A processor ID identifies a physical processor or a
logical process in a system. Processor IDs are
globally unique.
System Task
• A System Task is a schedulable unit of execution in
the underlying operating system (a thread on Solaris
or Windows NT, a task on VxWorks or pSOS).
• A TAPA Task must be attached to a System Task in
order to be activated.
• Once a TAPA Task is attached to a System Task, the
System Task schedules activation of the TAPA Task
based on the TAPA Task’s priority and on incoming
events.
• Any number of TAPA Tasks can be attached to a
System Task.
Permanent Task
• A Permanent Task is a specialized TAPA Task
• Its behavior is similar to an ‘idle’ task on a real time
operating system.
• A Permanent Task has the following features:
– It is usually implemented as a low priority task
(relative to the TAPA Task).
– It is activated irrespective of whether there is a
message for it or not.
– Based upon the operating system scheduler, it
may be activated only when no normal TAPA Task
can be run.
Driver Task
• A Driver Task is a specialized TAPA Task that can be
used to route messages across address space
boundaries.
• It is identified by a channel instance ID and not by
entity, instance, and processor IDs.
Memory
• Memory is divided into one or more regions.
• Region attributes:
– May be a contiguous block
– May or may not be protected
– May physically exist on different boards
– May be SRAM or DRAM
– May be shared memory
• A region is identified by a region ID.
• Each region is handled by a memory manager which
is responsible for handling allocation and deallocation
requests.
• Memory regions are divided into one or more pools.
A memory pool is identified by a pool ID.
Memory Models
There are two types of memory:
– Static Memory: Static buffers are allocated from

static memory and each static buffer has to be
contiguous.
– Dynamic Memory: Messages are allocated from
dynamic memory and a message may be
contiguous or disjointed.
Static Memory
• A task requests System Services to reserve space
from the specified region for the entire memory
requirements of the task’s structures (SGetSMem).
• System Services reserves this space.
• System Services returns a specific pool ID to the task
for the space it has reserved.
• A task allocates static buffers from the specific region
and pool.
• A static buffer is a unit of memory allocated from the
specified region and pool.
• A task overlays dynamic data structures on the static
buffers (SGetSBuf).
Dynamic Memory
• A task allocates dynamic buffers from the dynamic
memory.
• Dynamic buffer are used to build messages.
• The dynamic memory is identified by the specified
region and pool.
• The region and pool information are obtained from
the SAP to which a message is associated.
• A different region and pool may be assigned to each
SAP used by a task. The assignment is done by a
Configuration Request primitive issued by the layer
manager.
Message
• A message is a data abstraction that allows
information to be exchanged between TAPA tasks
(SGetMsg).
• Logically, a message is an ordered sequence of bytes
with no pre-defined size.
• System Services maintains some control information
in each message (sender, receiver, message priority,
and so on).
• The contents of the data part of the message are
bilaterally defined between the communicating tasks.
• Internally, a message is a STREAMS-standard
message.
• Messages are allocated from dynamic memory.
Message Priority
• Messages may be assigned priorities so that their

delivery can be scheduled ahead of other lower
priority messages.
Message Route
• Messages may be assigned routing information

relevant in getting the message across to the
destination task.
• In a fault tolerant system, messages tagged with a

certain route may be queued until their delivery to the
destination task is confirmed.
STREAMS Messages
mblk_t dblk_t
Queue b_next db_frtnp
pointers b_prev db_base
b_cont db_lim
b_rptr db_ref
b_wptr db_type
Data buffer
b_datap
read position
mblk_t
write position
Reference
count Type
Trillium Messages
dblk_t
mblk_t
(M_PROTO)
data buffer (SsMsgInfo)
dblk_t
mblk_t data buffer
(M_DATA)
dblk_t
mblk_t data buffer
(M_DATA)
Post Structure
• Every SAP stores a post structure (Pst).
• The SAP and its post structure are initialized by a

Configuration Request primitive invoked by the Layer
Manager.
Post Structure
typedef struct pst {
ProcId dstProcId; /* destination processor ID */
ProcId srcProcId; /* source processor ID */
Ent dstEnt; /* destination entity */
Inst dstInst; /* destination instance */
Ent srcEnt; /* source entity */
Inst srcInst; /* source instance */
Prior prior; /* priority */
Route route; /* route */
Event event; /* event */
Region region; /* region */
Pool pool; /* pool */
Selector selector; /* selector */
} Pst;
Post Structure Elements
The pst->event field:

• Indicates the primitive type.
• Is initialized at every primitive invocation.
• Is later used by the destination layer to decode the
received message back into the appropriate primitive.
Post Structure Elements
• If a primitive needs to be packed into a message,

pst->region and pst->pool point to the region
and pool from where the message is to be
allocated.
• In some cases, one of the primitive parameters
may be a message (carrying user data), then that
message can be used to pack primitive
parameters.
Terminology Quiz
1. A TAPA task must be attached to a _____ task in
2. A TAPA task is identified by what three types of
identifiers (IDs)?
3. What type of ID identifies a driver task?
4. There are ____ types of memory. Name them.
5. Messages are allocated from _____ memory.
6. SAPs and their post structures are initialized by a
________ primitive invoked by the ______.
Terminology Quiz -- Answers
1. A TAPA task must be attached to a system task
in order to be activated.
2. A TAPA task is identified by what three types of
identifiers (Ids)? Entity, Instance, and Processor.
3. What type of ID identifies a driver task? A
channel instance ID.
4. There are 2 types of memory. Name them. Static
and Dynamic.
5. Messages are allocated from dynamic memory.
6. SAPs and their post structures are initialized by a
configuration request primitive invoked by the
layer manager.
Agenda
• Terms
• System Services
• Flavors of System Services
System Services Overview
Operating
System
System Services Overview
• System Services abstracts the functionality of the

Operating System into a generic interface.
• This generic interface, which is called the System

Services Interface (SSI), isolates Trillium’s portable
layer software from the underlying Operating System.
• Various flavors of System Services
SSI Functionality
• SSI includes functionality for:

– Task management and scheduling
– Memory management
– Inter-task communication
– Message management
– Timing
– Driver/relay task management and scheduling
– Other miscellaneous calls
Task Management and Scheduling
Overview
• TAPA Task Information

• System Task Information
• Task Management
• Coupling with the Tasking Functions
TAPA Task Information
• TAPA Task information is contained in the TAPA
Task table.
• The TAPA Task table is indexed via the entity and
instance IDs.
• A write into the TAPA Task table is protected via a
table lock.
• If required, the ‘dep’ structure in the TAPA Task table
is filled in with the underlying OS-specific information.
• The figures on the next two slides illustrate TAPA

Task information.
Index table TAPA task table Table lock
tTskTbl[0]
tTskTbl[1] tTskTblSem
tTskIds[ent][inst]
Table
modification
index
nxtTTskEntry
SS_MAX_TTSKS
TAPA task count
numTTsks
TAPA task entry
TAPA task table • dep (dependent portion)

tTskTbl[0] • used (entry is occupied)
• ent (entity ID)
tTskTbl[1] • inst (instance ID)
• tskType (task type--normal/permanent)
• tskPrior (task priority)
• initTsk (initialization activation function)
• actvTsk (message activation function)
• sTsk (attached to this system task)
• nxt (tTskTbl modification index)
SS_MAX_TTSKS
System Task Information
System task table System task entry
sTskTbl[0]
• dep (dependent portion)
sTskTbl[1] • used (entry is occupied)
• termPend (task is being terminated)
• tskId (task ID)
• tskPrior (task priority)
• dQ (demand queue)
• tTsks (table of attached TAPA tasks)
• numTTsks (count of attached TAPA tasks)
• lock (for attached task table access)
• nxt (sTskTbl modification index)
Table lock Table

SS_MAX_STSKS
modification
System task count index
sTskTblLock
numSTsks nxtSTskEntry
Task Management
• The task management calls are:
– SRegTTsk()
– SDeregTTsk()
– SCreateSTsk()
– SDestroySTsk()
– SAttachTTsk()
– SDetachTTsk()
Task Management
SRegTTsk •Register a layer

SCreateSTsk •Create system task
SAttachTTsk •Attach TAPA task
System Services Trillium Layer Stack Manager
System Task
Tasking Functions--Coupling
• Tight coupling with tasking functions:
– Any two TAPA tasks that are tightly coupled need
to attach to the same system task.
• Loose coupling with tasking functions:

– Any two TAPA tasks that are loosely coupled can
attach to either the same or different system tasks.
SSI Functionality
• SSI includes functionality for:

– Timing
– Other miscellaneous
Memory Management
Overview
• Memory Information
• Memory Region Calls
• Mapping Pool ID to Size
• Typical Pool Configuration
• Memory Allocation
• Static Memory Calls
• Functions:
– SGetSMem
– SGetSBuf
– SPutSBuf
Memory information
Region table
regionTbl[0]
Region entry
regionTbl[1]
• used (entry is occupied)
• start (start address of memory region)
SS_MAX_REGS • size (size of memory region)
• regCb (region control block)
Region count • flags (memory flags)
• poolTbl (table of pools in the region)
numRegions
• numPools (count of pools)
• alloc (pointer to memory allocation function)
• free (pointer to memory freeing function)
Table lock
• ctl (pointer to memory control function
regionTblSem
Memory Information
Pool entry
• type (dynamic or static)
• u (union)
• dynamic pool entry
• specific pool entry
• size (for use in the SAlloc() call)
Dynamic pool entry

Specific pool entry
Memory Region Calls
• Memory related calls include:
– SRegRegion():Registers the specified region
with System Services
– SDeregRegion():Deregisters the specified

region with System Services
– SAlloc():Allocates memory from the specified

region
– SFree():Deallocates memory from the specified

region
Pool ID to Size
• System Services defines an array called

cfgRegInfo of type SsRegCfg. Each array
represents a region that has been registered with
System Services.
• Each element of array cfgRegInfo contains pool

configuration information for each region.
• The pool configuration information provides a

mapping of pool ID to size for dynamic memory N1
allocation.
Slide 43
N1 Nitin, 4/13/2004
Typical Pool Configuration
PUBLIC SsRegCfg cfgRegInfo[SS_MAX_REGS] =

{
{
SS_DFLT_REGION, SS_MAX_POOLS_PER_REG,
{
{ SS_POOL_DYNAMIC, 48 },
{ SS_POOL_DYNAMIC, 1600 }
}
}
};
Memory Allocation
• Static memory calls use the region and size as

parameters.
• Dynamic memory calls use region and pool Id as

parameters, pool ID is then mapped to a size (see
previous two slides).
• The region ID and size are then used in the

SAlloc() call.
Static Memory Calls
• SGetSMem()
– Request the ID of a specific pool containing at
least the specified amount of memory.
– Current implementation is empty.
• SPutSMem()
– Release a specific pool ID.
– Current implementation is empty.
Static Memory Calls
• SGetSBuf()
– Allocate a block of memory of the specified size.
– Currently maps directly to SAlloc()
• SPutSBuf()
– Release an allocated block of memory.
– Currently maps directly to SFree()
SGetSBuf
• Allocates a static buffer of the specified size from the

specified memory region and pool.
Static Memory
SGetSBuf
System Services Layer Manager
Task {ENTXX, INSTXX)
CfgReq
(Lower
SAP)
SGetSBuf
(region, pool,
**bufPtr,
size)
Lower
SAP
SPutSBuf
• Deallocates a buffer of the specified size back to the

specified memory region and pool.
SPutSBuf
CntrlReq
(Delete
Lower SAP)
SPutSBuf
(region, pool,
*buf, size)
Lower SAP
SPutSBuf
CfgReq
(Delete
Lower SAP)
SPutSBuf
(region, pool,
*buf, size)
SSI Functionality
• The SSI includes functionality for:

– Timing
Inter-task Communication
Overview
• Functions:
– SPstTsk:Routes a message from a source task
to a destination task.
•Dequeue message
•Copy contents of post structure
SPstTsk
from message Layer 3
•Identifies destination task from
pst->dstEnt, pst- actvTsk(Pst *pst,
>dstInst Buffer *mBuf)
•Invokes task’s activation •Invoke the primitive pointed to SAP SAP
function by the pst->event field
selector = loosely coupled

•Copy contents of post structure
into the message dstEnt
•Queue message for delivery to dstInst

the destination task
•SPstTsk returns Pst
SPstTsk (Pst *pst, Buffer *mBuf) SAP SAP
Primitive message
System Services
Layer 2
Review
1. TAPA task information is contained in the _____?
2. ______ information provides a mapping of pool ID to
size.
3. _____ reserves _____ memory of the specified size
in the specified region and allots a specific pool ID to
reference this memory.
4. _____ routes a message from a ____ task to a ____
task.
5. _____ allocates memory from a specified region.
Review -- Answers
1. TAPA task information is contained in the TAPA task
table.
2. Pool configuration information provides a mapping
of pool ID to size.
3. SGetSMem reserves static memory of the specified
size in the specified region and allots a specific pool
ID to reference this memory.
4. SPstTsk routes a message from a source task to a
destination task.
5. SAlloc() allocates memory from a specified
region.
SSI Functionality

– Timing
Message Management
Overview
• Message Allocation
• Functions:
– SGetMsg
– SGetDBuf
– SAddPstMsg
– SAddDBufPst
– SAddPstMsgMult
– SAddPreMsg
– SAddPreMsgMult
– SPutMsg
Message Allocation
• Protocol layers use the SGetMsg() call to allocate a
message.
• System Services calls SAlloc() to retrieve a
message block, a data block, and a data buffer large
enough to contain an SsMsgInfo structure.
• This initial message buffer holds control information
about the message.
• The pool ID passed to SGetMsg() is translated into
a size using the information in the region table.
• This size is the size of the data buffer to be allocated
for following message buffers that hold layer data.
SGetMsg
• Allocates a message from the specified region and

pool and initialize its data contents to be empty.
Message
SGetMsg •Data indication received in message
System Services •Send back Data Response

•First get empty message from SSI
SGetMsg
(region, pool,
**mBufPtr) •Fill message with Data Response
Message
•Send message
(Data Confirm)
Layer 3
Message
(Data Indication)
Layer 2
SGetMsg
SGetMsg(Region region, Pool
*mBufPtr pool, Buffer **mBufPtr)
mblk_t dblk_t
b_next db_frtnp
b_prev db_base
b_cont db_lim
b_rptr db_ref
b_wptr db_type
MSGINFO
b_datap
Reference
count = 1
System
Type
Services SS_M_DATA
SGetDBuf
• Allocates a dynamic buffer from the specified region

and pool and initializes its data contents to be empty.
• A message consists of a control triplet and a data

triplet. SGetMsg allocates a control triplet and
SGetDBuf allocates a data triplet. Internally,
SGetMsg calls SGetDBuf.
• In most cases, a user of System Services does not

call SGetDBuf directly.
SGetDBuf
SGetDBuf(Region region, Pool
*BufPtr pool, Buffer **BufPtr)
mblk_t dblk_t
b_next db_frtnp
b_prev db_base
b_cont db_lim
b_rptr db_ref
b_wptr db_type
Data Buffer
b_datap
System Reference
count = 1 Type
Services SS_M_DATA
SAddPreMsg
• Adds one byte of data to the beginning of the

message.
• Increments message length by one.
SAddPreMsg
SAddPreMsg(Data data, Buffer,
*mBuf)
dblk_t
mblk_t SsMsgInfo
(M_PROTO)
dblk_t
mblk_t data buffer
(M_DATA)
1 2 3 4 5 6 7
Each byte of data added to the beginning of the message comes

after each invocation of SAddPstMsg.
System
Services
SAddDBufPst
• Add a data buffer to the end of the specified message

buffer.
SAddPreMsgMult
• Copies the specified number of bytes to the

beginning of the message.
• Increments message length by the specified count.
SAddPstMsg
• Adds one byte of data to the end of the message.

• Increments message length by one.
SAddPstMsg
SAddPstMsg(Data data, Buffer,
*mBuf)
dblk_t
mblk_t SsMsgInfo
(M_PROTO)
dblk_t
mblk_t data buffer
(M_DATA)
1 2 3 4 5 6 7
Each byte of data added to the end of the message comes after each
invocation of SAddPreMsg.
System
Services
SAddPstMsgMult
• Copies the specified number of bytes to the

beginning of the message.
• Increments message length by the specified count.
SPutMsg
• Deallocates a message.
• Data buffers attached to the message are returned to
the dynamic memory pool from where they were
allocated.
Review
• Identify the following functions:
– SGetMsg
– SGetDBuf
– SAddPreMsg
– SAddPreMsgMult
Review
• Identify the following functions:
– SGetMsg: Used by protocol layers to allocate a
message from a specified region and pool
– SGetDBuf: Allocates a dynamic buffer from a
specified region and pool
– SAddPreMsg: Adds one byte of data to the front of
a message
– SAddPreMsgMult: Copies the specified number
of bytes to the start of a message
SSI Functionality

– Timing
Timing
Overview
• Timer Information
• Timer Management
Timer Information
Timer table Timer entry
tnrTbl[0]
tmrTbl[1] • used (entry is occupied)
• tmrId (timer ID)
• ownerEnt (owner TAPA task entity ID)
• ownerInst (owner TAPA task instance ID)
• interval (period of timer)
• tmrActvFn (timer activation function)
• mBuf (timer message buffer)
• nxt (tmrTbl modification index)
Table lock Table

SS_MAX_TMRS
modification
Timer count index
tmrTblLock
numTmrs nxtTmrEntry
Timer Management
• Timer management calls include:
– SRegTmr(): Registers a timer with System

Services.
– SDeregTmr(): Deregisters a timer with System
Services.
Timer Management
D
e
Layer ‘x’
m
a
n Layer ‘y’
d SRegTmr()
Layer ‘z’ System Services
q
u Attached TAPA tasks
e tmrActvFn()
u
e System task ‘A’
ssDmndQPutLast()
‘A’
SSI Functionality

– Timing
Driver Task Management
Overview
• Driver Task Information

• Driver Task Management
• Driver Task Usage
Driver Task Information
Driver task table
Driver task entry
drvrTskTbl[0]
drvrTskTbl[1]
• used (entry is occupied)
• channel (channel ID)
• actvTsk (message activation function)
• isTsk (interrupt service activation function)
• low (low processor ID)
• high (high processor ID)
SS_MAX_DRVRTSKS • lock (to serialize calls to activation functions)
Driver task count

numDrvrTsks
Driver Task Management
• Driver task management calls include:

– SRegDrvrTsk()
– SSetIntPend()
• All driver data structures and code are conditionally

included with the SS_DRVR_SUPPORT macro.
SRegDrvrTsk
• Registers two driver routines with System Services.

• The driver activation function routine routes
messages to and from tasks outside the context of
System Services.
SRegDrvrTsk
• When the driver activation function routine routes
messages to tasks outside the context of System
Services:
– System Services receives a message posted by a
task (SPstTsk).
– System Services identifies the message as
destined to a task outside the context of System
Services (through the foreign processor ID value
in the pst->dstProcId field).
– System Services packs the channel instance
associated with the foreign processor ID into the
message.
SRegDrvrTsk
• When the driver activation function routine routes

messages to tasks outside the context of System
Services (continued):
– System Services hands over the message to the
driver activation function handler.
– The driver activation function handler is
responsible for the delivery of the message.
– The driver activation function unpacks the channel
instance from the message, using it to identify the
destination to which to route the message.
SRegDrvrTsk
• When the driver interrupt service routine receives
messages from tasks outside the context of System
Services:
– The driver interrupt service routine is invoked by
System Services.
– The driver interrupt service routine is invoked either
periodically or in a deferred processing mode
(SSetIntPend).
– If driver interrupt service routine is invoked
periodically it checks for the receipt of a message.
SRegDrvrTsk
• When the driver interrupt service routine receives
messages from tasks outside the context of System
Services (continued):
– If the message format is not the same as the System
Service message format, then the received message
is copied into a System Service message.
– If required, a post structure is constructed
– Message is posted (SPstTsk).
– System Services is responsible for the delivery of the
message.
Driver Task Usage
Lower SAPs
Layer N+1 pst->dstProcId = y; Relay
Processor ID range (driver task)
Relay low <= x <= high
(driver task) Layer N
Processor ID range
low <= y <= high Upper SAPs
pst->dstProcId = x;
System Services System Services
Processor ID ‘x’ Processor Processor ID ‘y’

boundary
Driver Task Usage
isTsk()
Layer N+1 Relay

(driver task)
Relay actvTsk()
(driver task) Layer N
SPstTsk() SSetIntPend()
System Services System Services
Processor ID ‘x’ Processor Processor ID ‘y’

boundary
SSI Functionality

– Timing
Other Miscellaneous Calls
Overview
• Queue Information
• Queue Management
• A Few Esoteric System Services:
– SHoldInt
– SRelInt
– SEnbInt
– SDisInt
– SPutVect
– SGetVect
Queue Information
The Queue data structure has the following features:

• Stores Trillium messages.
• Is internally a doubly linked list.
• Uses pointers within the message to queue it.
• Queue operations do not use any memory resources.
• There is no size limitation imposed by the queue.
Queue Management
The following functions are queue management calls:
– SInitQueue()
– SQueueFirst(), SQueueLast()
– SDequeueFirst(), SDequeueLast()
– SFlushQueue()
– SCatQueue()
– SFndLenQueue()
– SExamQueue()
– SAddQueue()
– SRemQueue()
A Few Esoteric System Services
• SHoldInt
• SRelInt
• SEnbInt
• SDisInt
• SPutVect
• SGetVect
Esoteric System Services, Continued
• SDisInt() and SEnbInt()
– Parameters: none.
– Disable all interrupts and enable all interrupts.
– All code between calls to these should be non-interruptible.
– Used only in a few products and can be empty on high level
operating systems like UNIX.
• SHoldInt() and SRelInt()
– Parameters: none.
– Set the IRQ level to mask out the timer interrupt but permit
other interrupts at higher IRQ level through, and reverse.
– Used only in a few products and can be empty on high level
operating systems like UNIX.
Esoteric System Services, Continued
• SPutVect() and SGetVect()
– Parameters: vector number and vector function
handler.
– Insert the vector function handler at the specified
vector offset.
Review
1. _______ registers a timer with System Services.
2. Driver task management calls include ___ and ___.
3. The driver interrupt service routine is invoked when
messages are received from ____ the context of
System Services.
4. To enable and disable interrupts, what functions are
used?
5. True or False: Queue operations use memory
resources.
Review
1. SRegTmr() registers a timer with System Services.
2. Driver task management calls include
SRegDrvrTsk() and SSetIntPend().
3. The driver interrupt service routine is invoked when
messages are received from outside the context of
System Services.
4. To enable and disable interrupts, what functions are
used? SEnbInt() and SDisInt().
5. True or False: Queue operations use memory
resources. False. These operations use no memory
resources.
Agenda
• Terms
• System Services
• Flavors of System Services
• Trillium’s SSI implementations are composed of two

parts:
– Core System Services (platform independent)
– Dependent System Services (platform dependent)
OS
Core System Services independent
portion
SSI-specific to SSI-specific to SSI-specific to SSI-specific to OS

VxWorks Solaris Threads Win/NT pSOS dependent
portion
Operating System
VxWorks, Solaris Threads, Win/NT, pSOS
Core System Services
• Core System Services includes:
– All platform independent system services functions.
– Data structure definitions that are used globally across all
implementations.
– A generic mechanism for implementations to include
platform-dependent data into the core data structures.
– Wrapper functions for a number of platform-specific system
services functions to perform tasks such as table lookups,
free entry location, locking, and so on.
– A clearly defined interface to the platform dependent portion
of the implementation (the SSD interface).
SSI-Specific to VxWorks
• VxWorks is a commercial Real Time Operating

System (RTOS) from Wind River Systems.
• VxWorks/Tornado System Services is a System

Service implementation over the VxWorks operating
system.
VxWorks SSI
• Supports both multi-threaded and single-threaded

operations (configurable).
• Provides calls that are thread-safe within the Trillium
stack framework.
• Provides tasking, timing, memory management,
inter-task communication, and other miscellaneous
functionality, optimized for event-driven systems.
• Provides priority-based scheduling of tasks and

message delivery.
• Separates memory management from the core
system services, thereby permitting the use of
different, specialized memory managers, if required.
• Uses the STREAMS message buffer format
internally.
• Permits errors to be logged to a console, if available.
SSI-Specific to Solaris Threads
• Multi-threaded System Services - Solaris is a System

Service implementation which makes use of the
thread service available in Solaris 2.4 and higher.
• This flavor of System Services is ported over the

thread library of Solaris.
MTSS SSI
• Supports both multi-threaded and single-threaded

operations (configurable).
• Provides calls that are thread-safe within the Trillium
stack framework.
• Provides tasking, timing, memory management,
inter-task communication and other miscellaneous
functionality, optimized for event driven systems.
• Provides priority-based scheduling of tasks and
message delivery.
• Separates memory management from the core
system services, thereby permitting the use of
different, specialized memory managers, if required.
• Utilizes POSIX calls exclusively, thereby making it
simpler to port to other POSIX- compliant systems.
• Uses the STREAMS message buffer format
internally.
• Permits errors to be logged to a console, if available.
SSI-Specific to Windows NT
• MTSS-NT is a System Services implementation

which makes use of the thread service available in
WIN/32.
• This flavor of System Services is ported over the

thread library of WIN/32.
Windows NT SSI
• Multi-threaded design provides a scalable

environment in both a single-threaded mode or a
multi-threaded mode.
• NTSS is designed to provide a set of scheduling,
memory management and timing services to ensure
the orderly and fair allocation of resources for event
driven systems.
• Provides low overhead dynamic buffer pools using a
design that allows the arbitrary arrangement of pools
shared between any pair of processors.
• Provides low overhead priority based scheduling
using a demand queue design that allows an
arbitrary arrangement of communications channels
between any pair of processors.
• Provides low overhead timing design that can
provide timing ticks over a wide range of values.
• Provides a mechanism for creating user threads,
system tasks, TAPA tasks and has a flexible
mapping mechanism between system tasks and
TAPA tasks.
• Provides a way to use a native memory manager or
any other custom memory manager to manage
memory region(s).
SSI-Specific to pSOS
• pSOS is a commercial Real Time Operating

System (RTOS) from Integrated Systems, Inc.
• pSOS/pRISM+ System Services is a System

Service implementation over the pSOS operating
system.
pSOS SSI
The pSOS SSI interface:

• Runs on the pSOS+ kernel (single processor
kernel).
• Runs on the pSOS+m kernel (multiprocessing
kernel), but does not invoke any of the services that
are specific to the pSOS+m kernel.
• Maps each System Task to a pSOS+ task.
• Operates in either single thread mode or multi-
thread mode. In the single thread mode, a single
System Task handles all the TAPA Tasks. In multi-
thread mode, multiple System Tasks can be used
to handle the TAPA tasks.
• Uses the common memory manager supplied by
Trillium as part of pSOS/pRISM+ System Services.
• Uses the STREAMS message buffer format.
SSI – SDK
• The System Services Interface – Software
Development Kit (SSI – SDK) provides a quick,
efficient, and flexible way to implement the system
services interface on any platform, and thereby to
run any of Trillium’s protocol layers.
• SSI-SDK implements all platform-independent

primitives that constitute the system services
interface, by providing a clearly defined mechanism
for implementing all platform-dependent primitives
on any target platform.
SSI - SDK
Trillium’s OS Partners
The following companies and their corresponding RTOS
(Real Time Operating System) are certified by
Trillium Digital Systems as being “Trillium
Compliant”:
• ENEA OSE
• LynuxWorks LynxOS
Summary
In this presentation, you have reviewed:
• The System Services Interface and its functionality,

including important concepts and terms.
• The architecture of the System Services Interface,
and how it isolates Trillium’s portable layer software
from the underlying operating system.
• The different flavors of System Services and their
individual functionality.
SSI Review Questions
1. The System Services Interface can be defined as:
a) A generic interface that replaces the underlying
operating system with a Trillium-specific OS
b) A generic interface that isolates Trillium’s portable
layer from the underlying operating system
c) A means of establishing multiple product
relationships
d) All of the above
e) None of the above
2. A TAPA Task is identified by:
a) Only an entity ID
b) An entity ID and an instance ID
c) An entity ID, an instance ID, a channel ID, and a
processor ID
d) An instance ID and a processor ID
e) An entity ID, an instance ID, and a processor ID
3. True or False:
A permanent task can only be activated when there
is a message for it.
4. True or False:
TAPA tasks must be attached to a system task in
5. Identify the following:
SRegTTsk
SGetSMem
SPstTsk
SAddPreMsg
SSI Review -- Answers
1. B
2. E
3. False
4. True
5. SRegTTsk registers a task’s initialization function
and activation function with system services.
SGetSMem reserves static memory of a specified
size in a specified region and allots a specific pool
ID to reference this memory. SPstTsk is the
message passing function. SAddPreMsg adds a
byte of data at the head of a message.

SSI Tutorial 1079003.11

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SSI Tutorial 1079003.11

Uploaded by

Copyright:

Available Formats

System Services Interface (SSI)

This tutorial is supplemented by other presentations that

This tutorial should be read only after the Trillium

By the end of this presentation you will be able to:

• Define what the System Services Interface is, give an

Flavors of System Services

TAPA Task Message

There are two types of memory:

– Static Memory: Static buffers are allocated from

• Messages may be assigned priorities so that their

• Messages may be assigned routing information

• In a fault tolerant system, messages tagged with a

• Every SAP stores a post structure (Pst).

• The SAP and its post structure are initialized by a

The pst->event field:

• If a primitive needs to be packed into a message,

• Flavors of System Services

• System Services abstracts the functionality of the

• This generic interface, which is called the System

• Various flavors of System Services

• SSI includes functionality for:

• TAPA Task Information

• The figures on the next two slides illustrate TAPA

TAPA task table • dep (dependent portion)

Table lock Table

SRegTTsk •Register a layer

System Services Trillium Layer Stack Manager

• Loose coupling with tasking functions:

• SSI includes functionality for:

Dynamic pool entry

Specific pool entry

– SDeregRegion():Deregisters the specified

– SAlloc():Allocates memory from the specified

– SFree():Deallocates memory from the specified

• System Services defines an array called

• Each element of array cfgRegInfo contains pool

• The pool configuration information provides a

PUBLIC SsRegCfg cfgRegInfo[SS_MAX_REGS] =

• Static memory calls use the region and size as

• Dynamic memory calls use region and pool Id as

• The region ID and size are then used in the

• Allocates a static buffer of the specified size from the

Task {ENTXX, INSTXX)

• Deallocates a buffer of the specified size back to the

• The SSI includes functionality for:

selector = loosely coupled

•Queue message for delivery to dstInst

SPstTsk (Pst *pst, Buffer *mBuf) SAP SAP

• The SSI includes functionality for:

• Allocates a message from the specified region and

System Services •Send back Data Response

• Allocates a dynamic buffer from the specified region

• A message consists of a control triplet and a data

• In most cases, a user of System Services does not

• Adds one byte of data to the beginning of the

Each byte of data added to the beginning of the message comes

• Add a data buffer to the end of the specified message

• Copies the specified number of bytes to the

• Adds one byte of data to the end of the message.

• Copies the specified number of bytes to the

• The SSI includes functionality for:

Table lock Table

– SRegTmr(): Registers a timer with System

• The SSI includes functionality for:

SPstTsk (Pst pst, Buffer mBuf) SAP SAP