Chapter 18 Device Management —— Overview

Chapter 18 Device Management—— Overview

Outline • DDI / DKI Interface etc • Device Driver Entry Points • Kernel And Device Tree • Multithreading And Event

Introduction To DDI / DKI Interface • DDI－Device Driver Interface • DKI－Driver-Kernel Interface • The DDI/DKI interfaces are provided for driver portability. • With DDI/DKI, developers can write driver code in a standard fashion without having to worry about hardware or platform differences.

DDI / DDK Interface In Solaris • The Solaris 10 DDI/DKI, like its SVR4 counterpart, is intended to standardize and document all interfaces between device drivers and the rest of the kernel • The Solaris 10 DDI/DKI enables platform-independent device drivers to be written for Solaris 10 based machines.

Platform Independence • Platform independence is accomplished by the design of DDI in Solaris 10 DDI/DKI. The following main areas are addressed: • Dynamic loading and unloading of modules • Power management • Interrupt handling • Accessing the device space from the kernel or a user process, that is, register mapping and memory mapping • Accessing kernel or user process space from the device using DMA services • Managing device properties

What Is a Device Driver Entry Point? • An entry pointis a function within a device driver that can be called by an external entity to get access to some driver functionality or to operate a device. Each device driver provides a standard set of functions as entry points. • The Solaris kernel uses entry points for these general task areas: • Loading and unloading the driver • Autoconfiguring the device • Providing I/O services for the driver

Some Entry Points Type • Entry Points Common to All Drivers • Some operations can be performed by any type of driver, such as the functions that are required for module loading and for the required autoconfiguration entry points. • Entry Points for Block Device Drivers • Devices that support a file system are known as block devices. Drivers written for these devices are known as block device drivers. • A block device driver can also provide a character driver interface to allow utility programs to bypass the file system and to access the device directly.

Some Entry Points Type • Entry Points for Character Device Drivers • Character device drivers normally perform I/O in a byte stream. • Character device drivers can also provide additional interfaces not present in block drivers. • The main task of any device driver is to perform I/O, and many character device drivers do what is called byte-stream or character I/O. • The driver transfers data to and from the device without using a specific device address.

Some Entry Points Type • Entry Points for STREAMS Device Drivers • STREAMS is a separate programming model for writing a character driver. • Devices that receive data asynchronously, such as terminal and network devices, are suited to a STREAMS implementation • STREAMS device drivers must provide the loading and autoconfiguration support

Some Entry Points Type • Entry Points for Memory Mapped Devices • For certain devices, such as frame buffers, providing application programs with direct access to device memory is more efficient than byte-stream I/O. • Applications can map device memory into their address spaces using the mmap(2) system call. • Drivers that define the devmap(9E) entry point usually do not define read(9E) and write(9E) entry points, because application programs perform I/O directly to the devices after calling mmap(2).

Some Entry Points Type • Entry Points for the Generic LAN Device (GLD) Driver • Entry Points for SCSI HBA Drivers • Entry Points for PC Card Drivers

What Is the Kernel? • The Solaris kernel is a program that manages system resources. • The kernel insulates applications from the system hardware and provides them with essential system services • The kernel consists of object modules that are dynamically loaded into memory when needed.

What Is the Kernel? • The Solaris kernel can be divided logically into two parts: • Kernel: Manages file systems, scheduling, and virtual memory. • I/O subsystem: Manages the physical components.

What Is the Kernel?

Overview of the Device Tree • Devices in the Solaris OS are represented as a tree of interconnected device information nodes. • The device tree describes the configuration of loaded devices for a particular machine. • The system builds a tree structure that contains information about the devices connected to the machine at boot time.

Root node represents the platform. Device Tree Components bus nexus device provides bus mapping and translation services Leaf devices are typically peripheral devices

Displaying the Device Tree • The device tree can be displayed in three ways: • The libdevinfo library provides interfaces to access the contents of the device tree programmatically. • The prtconf(1M) command displays the complete contents of the device tree. • The /devices hierarchy is a representation of the device tree. Use the ls(1) command to view the hierarchy.

Binding a Driver to a Device • In addition to constructing the device tree, the kernel determines the drivers that are used to manage the devices. • Binding a driver to a device refers to the process by which the system selects a driver to manage a particular device. • The binding name is the name that links a driver to a unique device node in the device information tree.

Locking Primitives • In Solaris a kernel thread can be preempted at any time to run another thread. • The kernel provides a number of locking primitives to prevent threads from corrupting shared data. • Mutual exclusion locks • Readers/writer locks • Semaphores

Storage Classes of Driver Data • The storage class of data is a guide to whether the driver might need to take explicit steps to control access to the data. The three data storage classes are: • Automatic (stack) data. • Global static data. • Kernel heap data.

Mutual-Exclusion Locks • A mutual-exclusion lock, or mutex, is usually associated with a set of data and regulates access to that data. • Mutexes provide a way to allow only one thread at a time access to that data.

Using Mutexes • Every section of the driver code that needs to read or write the shared data structure must do the following tasks: • Acquire the mutex • Access the data • Release the mutex

Readers/Writer Locks • A readers/writer lockregulates access to a set of data. • Many threads can hold the lock simultaneously for reading, but only one thread can hold the lock for writing. • Most device drivers do not use readers/writer locks. These locks are slower than mutexes.

Semaphores • Counting semaphores are available as an alternative primitive for managing threads within device drivers. • The semaphore functions are: • sema_destroy(9F) Destroys a semaphore. • sema_init(9F) Initialize a semaphore. • ………………… • sema_v(9F) Increment semaphore and possibly unblock waiter.

Thread Synchronization • In addition to protecting shared data, drivers often need to synchronize execution among multiple threads. • Condition variables are a standard form of thread synchronization. They are designed to be used with mutexes.

Thread Synchronization • To use condition variables, follow these steps in the code path waiting for the condition: • Acquire the mutex guarding the condition. • Test the condition. • If the test results do not allow the thread to continue, use cv_wait(9F) to block the current thread on the condition. • After the test allows the thread to continue, set the condition to its new value. For example, set a device flag to busy. • Release the mutex.

Choosing a Locking Scheme • The locking scheme for most device drivers should be kept straightforward. • Using additional locks allows more concurrency but increases overhead. Using fewer locks is less time consuming but allows less concurrency • Avoid holding mutexes for long periods of time.

Choosing a Locking Scheme • Use the following guidelines when choosing a locking scheme: • Use the multithreading semantics of the entry point to your advantage. • Make all entry points re-entrant. • If your driver acquires multiple mutexes, acquire and release the mutexes in the same order in all code paths. • Hold and release locks within the same functional space. • Avoid holding driver mutexes when calling DDI interfaces that can block

Introduction to Events • Anevent is a message that a device driver sends to interested entities to indicate that a change of state has taken place. • Events are implemented in the Solaris OS as user-defined, name-value pair structures • Events are organized by vendor, class, and subclass.

Introduction to Events • Two methods for designers of user–level applications deal with events: • An application can use the routines in libsysevent(3LIB) to subscribe with the syseventd daemon for notification when a specific event occurs. • A developer can write a separate user-level application to respond to an event.

Log Events • Device drivers use the ddi_log_sysevent(9F) interface to generate and log events with the system. • A device driver performs the following tasks to log events: • Allocate memory for the attribute list • Add name-value pairs to the attribute list • Log the event in the sysevent queue • Call nvlist_free(9F) when the attribute list is no longer needed

Defining Event Attributes • Event attributes are defined as a list of name-value pairs. • The Solaris DDI provides routines and structures for storing information in name-value pairs. • A list of name-value list pairs can be placed in contiguous memory.

Reference • Jim Mauro, Richard McDougall, Solaris Internals-Core Kernel Components, Sun Microsystems Press, 2000 • Max Bruning, Threading Model In Solaris, Training lectures,2005 • Solaris internals and performance management, Richard McDougall, 2002 • Solaris Writing Device Drivers,2005

End

Chapter 18 Device Management —— Overview