Uniform Driver Interface: Difference between revisions
| [unchecked revision] | [unchecked revision] |
Content deleted Content added
Avoid confusion about variable-length argument lists |
m [Due to forum] Explained what modules are, minor clarification regarding chanels. |
||
Line 26:
Drivers are split into one or more modules. Once they run, they do so as driver instances: each device gets one logical instance. The reason I used the word "logical" is that it doesn't actually matter to the driver how the environment implements instances; if there are ''n'' SCSI devices of the same type installed on a system, there might only be one copy of the executable code in memory, yet ''n'' individual driver states (i.e., variables, open channels, etc.).
===Modules===
Drivers that are part of the same module can communicate. This is how driver topologies should be implemented.
===Regions===
Line 33 ⟶ 37:
===Channels===
The only way for regions to communicate is through channels. Channels are an IPC-agnostic abstraction of a bi-directional communication mechanism. Each of the two channel endpoints provide an ops vector, which is a set of entry points. They are referenced via handles of type udi_channel_t (check the definition of handles below). The channel operations along with the associated functionality is defined by metalanguages. Metalanguages are separately defined for each class of drivers, but we'll get to that soon.
All channel operation invocations have the following form:
| |||