|
|
| |
|
|
|
6.1 Overview
There are two types of UDI driver configuration: static configuration and dynamic configuration. Static configuration specifies the operational characteristics of the UDI driver and its related device and is set in the distribution package for that driver. Dynamic configuration is the result of using that UDI driver along with its static configuration in a running system.
6.2 Static Configuration
Each UDI driver is provided to end-users by distributing a driver package. That driver package includes the driver itself along with information describing the driver and the associated device; this latter information is the static configuration information for that UDI driver. The static configuration is specified by the UDI driver developer as part of UDI driver development and included in the distribution with standard UDI utilities.
6.2.1 Static Driver Properties
All UDI drivers (and libraries) have a set of static properties associated with them and contained in a separate file (udiprops.txt) that must accompany the driver installation package. These static properties describe the driver and its associated device. They provide identification information about the driver, including the name of the driver, the description of the device(s) that are managed by the driver, and the relationship between UDI objects used by the driver.
To provide the required level of UDI portability, no assumption can be made about the target system beyond the general configuration specified by the ABI binding for that target. Therefore the UDI static properties supply all additional information needed to configure and control a device in the target system, including obtaining operational configuration parameters from the user or system adminstrator.
All UDI drivers (and libraries) have a set of static properties associated with them and contained in a separate file (udiprops.txt), which is intended to accompany the driver installation package. The static properties file also indicates which additional files are needed to complete the package, including specifying driver source code files and build rules for source code distributions.
6.2.2 Initialization Structures
Each driver must contain a set of static initialization structures that describe the internal structure of the driver and the corresponding environment objects needed or referenced by the driver, as defined in Chapter 10, "Initialization". These structures are linked together and hung off of the driver's central initialization structure (udi_init_info). This allows the UDI environment to examine the structures before executing any driver code and determine and prepare for the operational needs of that driver. The initialization structures supplement the information specified in the static driver properties with information, such as sizes of structures, best contained in driver source code.
A similar approach is used in UDI metalanguage libraries, based on a udi_meta_info global variable in each library.
6.2.3 Building UDI Drivers
Each target environment for a UDI driver will probably have a different set of tools or names for those tools, as well as options appropriate to that toolset or environment that are required for building device drivers. To standardize this information, UDI defines the udibuild utility which is required for all UDI environments that support building UDI drivers from source code. The implementation of the udibuild utility and the operations it performs are defined by the target environment and will include compiling the various driver module source files to create the UDI driver.
The udibuild utility is designed to be portable and applies only to UDI driver builds; it replaces more conventional tools such as "make" and "build" which require additional system-specific information to operate correctly. The udibuild utility cannot be used for generic (non-UDI) purposes and uses the udiprops.txt static properties file to obtain information about the driver's source files and corresponding build options.
6.2.4 UDI Packaging
To portably distribute UDI drivers and libraries, UDI defines the packaging format and a tool that may be used to generate that package. This packaging format is understood by various UDI tools to assist in creating and installing packages and may be placed onto distribution media for physical distribution.
UDI defines the format of the package itself, but does not specify the methods which are to be used in placing that package on the distribution media. Local media access methods and utilities may be used since these activities are not covered by the UDI portability guarantees, but ultimately the package must be delivered to the UDI tools in its original form, as a hierarchy of files.
To create packages, UDI specifies the udimkpkg utility, which must be available on all UDI development environments and will create a UDI package from a set of UDI device driver source code and/or binary objects. The udimkpkg utility uses the information in the driver's static properties (from udiprops.txt) to locate the components of the package and construct the package itself. The udiprops.txt static properties file is also part of the package so that the proper information is available to the UDI package installation tools; for source distributions, it is included as a separate file; for binary distributions, is it encapsulated in the driver binary itself (often using a special section of the object file) by the udimkpkg tool.
6.2.5 UDI Package Installation
Once a package has been physically distributed to the target system, the system administrator uses the udisetup utility to install the package onto that system. The udisetup utility is defined to be present for all UDI target environments but its activities will be customized to the local environment to properly install the UDI driver and associated files.
The udisetup utility may invoke the udibuild utility for source code distributions. Not all environments are required to support source code distributions; thus, a particular environment might not include a udibuild utility. Such environments will not be able to utilize a UDI source code distribution.
6.3 Dynamic Configuration
6.3.1 Device Tree
The UDI target environment is typically described in terms of a "device tree", which represents the hardware topology for that environment. For example, the base of the tree may be the system board or processor-memory interconnect, which has one or more buses as its branches (children), each of which may have an adapter plugged into them as leaves (grandchildren).
The depth of the tree is system-specific and the presence of multiplexers will make this routing significantly more complex. Each node in the tree is potentially managed by a different driver (UDI or otherwise), depending on the type of device represented by each node.
6.3.2 Driver Instantiation
For each device tree node that is managed by a UDI device driver, the UDI environment will instantiate an instance of that device driver. If multiple devices of the same type are present in the device tree, the UDI environment may choose to use the same code segment for all of those devices but is required to instantiate a separate logical instance of the driver for each device. This instantiation creates independent driver instances that separately manage and operate their corresponding devices.
6.3.3 Device Node Enumeration and Attributes
Each UDI driver (except "leaf" drivers) assists in the creation of the device tree by enumerating each of its child devices for the UDI environment. During this enumeration, the driver specifies the enumeration attributes of that child, which allows the UDI environment to match those attributes with the information supplied in the installed UDI drivers' static properties, and therefore to locate the appropriate driver to manage each child device.
When each UDI driver instance is instantiated, that device/driver node will receive a set of instance attributes which describe that node. Some of these attributes will have been supplied by the parent in the form of enumeration attributes. Other attributes are supplied in the form of persistent attributes, which were set the last time this driver was instantiated (typically via system administrator input), and were preserved by the system in the persistent storage database (if it exists).
6.3.4 Driver Inter-Instance Binding
Each driver should use the information provided by its instance attributes to prepare for operation and then issue a metalanguage specific bind request to the parent device that enumerated it. Each metalanguage describes the details of the bind request for that metalanguage. Successful completion of that bind operation will supply all of the additional information needed by the UDI driver instance to manage its device. The UDI driver is then responsible for managing and operating its device until subsequently instructed to unbind, whereupon it will be removed from the device tree.
| |
|
|
|