Uniform Driver Interface

The official Project UDI logo

UDI stands for "Uniform Driver Interface". It is the specification of a framework and driver API / ABI that enables different operating systems (implementing the UDI framework) to use the same drivers. Conceived by several industry big players, it has fallen somewhat dormant, despite being functional and delivering on its promise.

UDI drivers are binary compatible across all UDI-implementing operating systems running on the same CPU family. They are also source compatible across all UDI-implementing operating systems. This means, a driver only has to be developed once.

While Microsoft Windows gets all the hardware drivers they want, and GNU discourages UDI for philosophical reasons, its advantages for hobbyist OS developers are obvious.

Why UDI?

UDI has several advantages over other existing driver interfaces which motivates developers to choose it above all others:

• Portability (both cross-OS and cross-platform), which was mentioned in the above section, is perhaps the primary concern for which UDI was developed in the first place. All we can hope for is that enough operating systems will embrace the model so we can actually take advantage of it.
• Performance is comparable or better than that of legacy drivers. Let's face it, performance is always important. UDI features a non-blocking model, besides the blocking one, a synchronization model for increased MP scalability and much more. UDI drivers have proven themselves over DDI drivers (and others).
• Compatibility has also been taken into account. UDI environments can be implemented regardless of the OS architecture (monolithic kernel vs. microkernel, POSIX vs. non-POSIX, etc.) with no extra overhead for any exotic design one might think of.
• Stability is usually overlooked by the design and falls back to the implementation phase. UDI tries to eliminate some categories of potential bugs, such as (but not limited to) resource leaks and deadlocks.
• Flexibility is another thing UDI has been designed mind with: not only in the way the specification was concieved (i.e., to be extensible), but also in the sense that it permits system programmers to apply techniques such as driver isolation, shadow drivers, etc. if they see fit to do so.

Description

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).

Try to imagine the logical topology of an I/O system. It's a tree: you have one central node (perhaps the system board) which has several children (say, buses). 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. 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.).

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 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.

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:

void meta_op(meta_cbtype_cb_t *cb, ...);

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 environemnt running an operation in the other region. The convention is for the operation to have the following declaration:

static void ddd_meta_op(meta_cbtype_cb_t *cb, ...);

The same observations as above apply, plus "ddd" being a driver-specific prefix.

Metalanguages

Metalanguages usually have a parent-child relationship, according to the tree representation explained earlier. However, this does not always hold. One good example is the Management Metalanguage. This metalanguage deals with 3 channels:

• The parent's management channel
• The child's management channel
• The child's bind channel

Don't worry if you don't understand the purpose of the management metalanguage yet. Everything will be explained in greater detail later; I was merely trying to point out this special kind of relationship that doesn't only include the parent and the child, it also includes the Management Agent.

Configuration

There's a special configuration method for static properties of UDI drivers using a file called udiprops.txt. This file is distributed independently in each driver package for source code distributions and linked into a special section (called .udiprops) for binary distributions.

The udiprops.txt file doesn't only allow for static configuration options, but is also used in the building process for UDI drivers since they do not use makefiles - not that it would be technically unfeasible. The UDI specification defines tools for building, packaging and installing UDI drivers for simplicity's sake since, unlike POSIX tools, they don't require operating systems to have any extra functionality (e.g., a VFS).

Data objects

There are several types of data we need to look at. First, there's modlue-global data - which resides in the .bss 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.

However, none of these are actually data objects. The difference between data types and data objects is that data objects get allocated via an UDI allocation interface. Let's take a look at the existing 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. There are several types of control blocks, the generic block type being udi_cb_t.

Initial state

This page is a stub.

You can help the wiki by accurately adding more contents to it.

Driver failures

This page is a stub.

You can help the wiki by accurately adding more contents to it.

Metalanguages

This page is a stub.

You can help the wiki by accurately adding more contents to it.

See also

• Combuster's effort on creating a graphics metalanguage

External Links

• Official website
• Reference implementation
• Deven Corzine's editorial
• UDI Driver Writer's Guide