|
Of course, udiprops.txt can be a lot more complex than this, I only wanted you to see what one looks like. You should check the specification for all compile options, statements and configuration options.
==Data objects==
There are several types of data we need to look at. First, there's modlue-global data - which resides in the .rodata section. The reason why this data is global is that it's read-only and thus won't cause any race conditions - remember that although only one thread of execution can be active per region, several regions of the same driver instance may run in parallel. Secondly, there's region-local and region-global data. Last but not least, function-local variables.
Region-local data is data private to a region. Being private makes it okay to move the region to a different location or domain without affecting any of the neighbouring regions. Region-global is data that is not particular to a channel or operation.
Data objects get allocated via an UDI allocation interface. Let's take a look at the existing types of data objects.
===Control blocks===
Control blocks are a semi-opaque (i.e., the driver doesn't see the whole data object) data type that are used in metalanguage operations. Once a block is sent via a channel operation it may not be referenced until the channel operation completes. The same is true for asynchronous service calls - the control block will only become available once the callback returns. The way you need to think about this is that a block is owned by only one region at a time and you transfer it from one place to another.
There are several types of control blocks, the generic block type being udi_cb_t. All other types of control blocks are supersets of the generic control block. Also, there is the notion of control block groups - control blocks are categorized into groups of control blocks of the same size. Control blocks within the same group can thus be used interchangeably using casts.
Each control block may own a scratch space which is driver-specific and must be preserved across asynchronous and service calls. The driver can change the size for its control blocks' scratch spaces and if any of these are zero in size, their pointers must not be dereferenced.
<source lang="c">
typedef struct {
udi_channel_t channel;
void *context;
void *scratch;
void *initiator_context;
udi_origin_t origin;
} udi_cb_t;
</source>
===Handles===
Handles are opaque objects, meaning that the driver does not know their internal representation in the UDI environment. You can implement this as simple (void *)s, internally casting them as pointers into the correct context, or have abstract types.
==Initial state==
| 