|
[[Image:Core_spec-8.gif|left|frame|alt=Environment|High level view of UDI environments]]
TheAn OSimplementation layerof thatthe dealsUniform withDriver UDIInterface driversspecification is calledknown anas a UDI environmentEnvironment. TheThere is a reference implementation available (see link below) putswhich quiteprovides ausable few environmentscode for someseveral ofexisting thekernels more(Linux, popularBSD, operatingSolaris), systemsand atit yourcan disposalbe (Linux,used Mach,the Darwin,basis Solarisfor anda FreeBSD)fresh -implementation. althoughKernel someenvironment ofimplementations themare mightresponsible befor outproviding ofthe date.Service ThisCall isinterfaces specified by the layerUDI youStandard; wanta kernel may choose to implement inthese orderas tonative enjoysystem UDIcalls, drivers.or Onevia thinglibrary environmentsextensions are-- liablethe fordecision is providingup serviceto callsthe implementer. There are two types of service calls recognized by the UDI paradigm: synchronous (which will return immediately to the caller - i.e., to the driver) and asynchronous (which work through a callback mechanism).
TryUDI todrivers imaginealso theactively logicaltake topologypart ofin anidentifying I/Otheir system.child It'sdevices aand tree:building youthe havekernel's onedevice centraltree. nodeBus (perhapsdrivers theenumerate systemchildren, board)and whichso has several children (say, buses)on. Each of these buses may have several controllers attached. Since the tree can be more than 2 layers deep, each node needs to enumerate its children, which in turn will need to enumerate theirs, and so on. UDI drivers for these devices will interact in a tree-like fashion just as the hardware does. Let's take a closer look at drivers themselves!
Drivers are split into one or more modules., Onceand theyeach run,module theyhas doat soleast asonce driverregion. instances:A eachdriver devicethat getshas onebeen logicalinstantiated instance.(executed, Theso reasonto Ispeak) useduses theIPC wordcalls ("logicalChannel operations") isto thatcommunicate itbetween doesn'tmodules actuallyand matterregions. toIf thea driver howis theused environmentto implementsinstantiate instances;more ifthan thereone aredevice ''n''(say, SCSIa devicesdisk ofdriver theused sameto typeinstantiate installedtwo onseparate adisk systemdevices), therethe mightchoice onlyof bewhether onethe copyactual ofdriver thecode executableis codemapped inusing memoryCopy-on-Write, yetor ''n''duplicated individualin drivermemory, statesetc (i.e.,is variables,up opento channels,the etc.)environment.
===Modules===
A module is essentially a single executable code object. Specifically, drivers can be broken into multiple executables. A large driver that may only need to load certain components and may not need all of its code in memory all the time may be implemented as a multi-module driver. This partitioning of the driver code into modules is up to the driver vendor of course. Most UDI drivers are expected to be single-module drivers, but complex drivers such as graphics card drivers, etc may be best implemented as multi-module drivers.
Drivers that are part of the same module can communicate. This is how driver topologies should be implemented.
===Regions===
Main article: [[ http://wiki.osdev.org/User:Gravaera/UDI_Regions | UDI Regions ]]
Driver instances are divided into regions, the unit of concurrent execution in UDI. UDI regions location- and instance-independent, meaning that they can be moved from one place to another without affecting any of the other regions because they share no common state. This is particularly interesting in multiprocessor systems (esp. NUMA) because an environment may separate regions due to performance and resource constraints. They are concurrent in the sense that there can only be one thread running in a region at any given time. If there's still code running in region context while an asynchronous service call returns, the callback procedure is put on a queue. This helps avoid all sorts of locking mechanisms and isn't really a performance bottleneck since there can be more than once region per instance and more than once instance per driver running at the same time. Since regions don't share any state it's safe to say that running them in parallel won't cause any race conditions. It's worth mentioning that, because of the separate states, the tasks performed by regions are mutually-exclusive (for instance a network driver might have one region that handles sending packets and another receiving). This is exactly why there is no performance bottleneck.
===Channels===
Main article: [[ http://wiki.osdev.org/User:Gravaera/UDI_Channels | UDI 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:
<source lang="c">void meta_op(meta_cbtype_cb_t *cb, /*, other arguments */);</source>
Where "meta" is a prefix specific to the metalanguage (e.g., udi or usbdi), "op" is the channel operation and "cbtype" is the control block type (read more on this below). Channel operations take zero or more parameters, depending on which operation we're talking about. The target channel is specified by the value of cb->gcb.channel.
This will result in the environment running an operation in the other region. The convention is for the operation to have the following declaration:
<source lang="c">static void ddd_meta_op(meta_cbtype_cb_t *cb /*, other arguments */);</source>
The same observations as above apply, plus "ddd" being a driver-specific prefix.
===Metalanguages===
| 