JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Writing Device Drivers     Oracle Solaris 11 Information Library
search filter icon
search icon

Document Information


Part I Designing Device Drivers for the Oracle Solaris Platform

1.  Overview of Oracle Solaris Device Drivers

2.  Oracle Solaris Kernel and Device Tree

3.  Multithreading

4.  Properties

5.  Managing Events and Queueing Tasks

6.  Driver Autoconfiguration

7.  Device Access: Programmed I/O

8.  Interrupt Handlers

9.  Direct Memory Access (DMA)

10.  Mapping Device and Kernel Memory

11.  Device Context Management

12.  Power Management

13.  Hardening Oracle Solaris Drivers

14.  Layered Driver Interface (LDI)

Part II Designing Specific Kinds of Device Drivers

15.  Drivers for Character Devices

16.  Drivers for Block Devices

17.  SCSI Target Drivers

18.  SCSI Host Bus Adapter Drivers

19.  Drivers for Network Devices

20.  USB Drivers

21.  SR-IOV Drivers

Part III Building a Device Driver

22.  Compiling, Loading, Packaging, and Testing Drivers

23.  Debugging, Testing, and Tuning Device Drivers

24.  Recommended Coding Practices

Part IV Appendixes

A.  Hardware Overview

B.  Summary of Oracle Solaris DDI/DKI Services

C.  Making a Device Driver 64-Bit Ready

Introduction to 64-Bit Driver Design

General Conversion Steps

Use Fixed-Width Types for Hardware Registers

Use Fixed-Width Common Access Functions

Check and Extend Use of Derived Types

Check Changed Fields in DDI Data Structures

buf Structure Changes


ddi_dma_cookie Structure Changes

csi_arq_status Structure Changes

scsi_pkt Structure Changes

Check Changed Arguments of DDI Functions

getrbuf() Argument Changes

drv_getparm() Argument Changes

delay() and timeout() Argument Changes

rmallocmap() and rmallocmap_wait() Argument Changes

scsi_alloc_consistent_buf() Argument Changes

uiomove() Argument Changes

cv_timedwait() and cv_timedwait_sig() Argument Changes

ddi_device_copy() Argument Changes

ddi_device_zero() Argument Changes

ddi_dma_mem_alloc() Argument Changes

Modify Routines That Handle Data Sharing

Data Sharing in ioctl()

Data Sharing in devmap()

Data Sharing in mmap()

Check Structures with 64-bit Long Data Types on x86-Based Platforms

Well Known ioctl Interfaces

Device Sizes

D.  Console Frame Buffer Drivers

E.  pci.conf File


Introduction to 64-Bit Driver Design

For drivers that only need support for the 32-bit kernel, existing 32-bit device drivers will continue to work without recompilation. However, most device drivers require some changes to run correctly in the 64-bit kernel, and all device drivers require recompilation to create a 64-bit driver module. The information in this appendix will help you to enable drivers for 32-bit and 64-bit environments to be generated from common source code, thus increasing code portability and reducing the maintenance effort.

Before starting to modify a device driver for the 64-bit environment, you should understand how the 32-bit environment differs from the 64-bit environment. In particular, you must be familiar with the C language data type models ILP32 and LP64. See the following table.

Table C-1 Comparison of ILP32 and LP64 Data Types

C Type
long long
long double

The driver-specific issues due to the differences between ILP32 and LP64 are the subject of this appendix.

In addition to general code cleanup to support the data model changes for LP64, driver writers have to provide support for both 32-bit and 64-bit applications.

The ioctl(9E), devmap(9E), and mmap(9E) entry points enable data structures to be shared directly between applications and device drivers. If those data structures change size between the 32-bit and 64-bit environments, then the entry points must be modified so that the driver can determine whether the data model of the application is the same as that of the kernel. When the data models differ, data structures can be adjusted. See I/O Control Support for 64-Bit Capable Device Drivers, 32-bit and 64-bit Data Structure Macros, and Associating Kernel Memory With User Mappings.

In many drivers, only a few ioctls need this kind of handling. The other ioctls should work without change as long as these ioctls pass data structures that do not change in size.