Uniform Driver Interface: Difference between revisions

[unchecked revision][unchecked revision]
Content deleted Content added
mNo edit summary
Line 18:
 
==Description==
 
[[Image:Core_spec-8.gif‎|left|frame|alt=Environment|High level view of UDI environments]]
 
The OS layer that deals with UDI drivers is called an UDI environment. The reference implementation (see link below) puts quite a few environments for some of the more popular operating systems at your disposal (Linux, Mach, Darwin, Solaris and FreeBSD) - although some of them might be out of date. This is the layer you want to implement in order to enjoy UDI drivers. One thing environments are liable for is providing service calls. There are two types of service calls regocnized 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).
Line 28 ⟶ 30:
 
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 MP 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 reutrns, the callback procedure is put on a queue. This helps avoid all sorts of locking mechanisms and isn't really a performance bottlneck 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.
 
[[Image:Core_spec-8.gif‎|left|frame|alt=Environment|High level view of UDI environments]]
 
===Channels===
 
The only way for regions to communicate is through channels. Channels are a bi-directional communication mechanism. Each of the two channel endpoints provide an ops vector, which is a set of entry points; as you will soon learn, there are no pre-defined entry points anywhere in the UDI business. 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: