<Subsystem

ACP/SETS files are XML documents that express the structure of MASCOT subsystems, defining the entities in them and their connectivity. The following describes the contents of these documents:

Each subsystem must have a name and a type. The name identifies the subsystem to the MASCOT machine, the type indicates how the entities it defines will be treated. If the type is global then the entities are incarnated and added to the global subsystem. Otherwise the entities are incarnated when the subsystem is started in some context. The type ‘handler’ identifies this subsystem as a handler for devices. A device will be able to name this subsystem as its handler; there is no other way to incarnate a handler. The ‘close_on_empty’ entry indicates whether the MASCOT Machine should terminate incarnations of this subsystem when all contained activities exit (endroot). The default behavior is to keep incarnations alive until they are explicitly terminated.

<SETS>

The top level tag. An ACP file may define one or more SETs. Each SET section defines entities that are either part of the global subsystem or named subsystems.

type=global/subsystem/handler
name=subsys-name
set=set-name
close_on_empty=true/false>

<entity-maps>

platform=platform-name >

Entity maps define mappings between platform specific implementation details and MASCOT implementation names on a per platform basis. All entities in a SET use MASCOT implementation names; these mappings define the relation between these names and the modules that implement them on a particular platform.

<entity-map

name=mascot-name

imp=implementation-descriptor />

An entity map binds a particular name to platform implementation mapping.

•
•
•

</entity-maps>

<entity-instances>

Entity instances sections define entities within the subsystem. Allowable entities are IDA (channel or pool), device (only in the global context), activity, and subsystem.