Chapter 18 Device Management Overview

1
Chapter 18 Device Management Overview
2
Outline

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

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

4
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-independen
  t device drivers to be written for Solaris 10
  based machines.

5
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

6
Outline

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

7
What Is a Device Driver Entry Point?

• An entry point is 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

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

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

10
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

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

12
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

13
Outline

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

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

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

16
What Is the Kernel?
17
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.

18
Device Tree Components
Root node represents the platform.
bus nexus device provides bus mapping and
translation services
Leaf devices are typically peripheral devices
19
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.

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

21
Outline

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

22
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

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

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

25
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

26
Readers/Writer Locks

• A readers/writer lock regulates 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.

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

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

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

31
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

32
Introduction to Events

• An event 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.

33
Introduction to Events

• Two methods for designers of userlevel
  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.

34
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

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

36
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

37
End