Oracle Solaris 9 手册：DDI 和 DKI 编程指南

需积分: 5 8 浏览量更新于2024-06-22 收藏 626KB PDF 举报

"DDI和DKI编程指南" Oracle Solaris 9操作系统提供了DDI（Device Driver Interface）和DKI（Driver-Kernel Interface）编程接口，用于开发和管理设备驱动程序。下面是DDI和DKI编程指南的详细解释： **DDI编程接口** DDI是Oracle Solaris操作系统提供的一种设备驱动程序编程接口，允许开发者创建和管理设备驱动程序。DDI提供了一组API（Application Programming Interface），用于与操作系统和设备进行交互。DDI编程接口包括以下几个部分： * 驱动程序开发：DDI提供了一组API，用于开发和管理设备驱动程序。 * 设备管理：DDI提供了一组API，用于管理设备的生命周期，包括设备的创建、删除、启动和停止。 * 设备交互：DDI提供了一组API，用于与设备进行交互，包括数据传输、控制命令和状态查询。 **DKI编程接口** DKI是Oracle Solaris操作系统提供的一种驱动程序-内核接口，用于管理驱动程序和内核之间的交互。DKI提供了一组API，用于管理驱动程序和内核之间的交互，包括： * 驱动程序注册：DKI提供了一组API，用于注册驱动程序，以便内核可以识别和加载驱动程序。 * 驱动程序管理：DKI提供了一组API，用于管理驱动程序的生命周期，包括驱动程序的加载、卸载和更新。 * 内核交互：DKI提供了一组API，用于与内核进行交互，包括数据传输、控制命令和状态查询。 **Properties and Data Structures** 在DDI和DKI编程接口中，Properties and Data Structures是非常重要的概念。Properties是指驱动程序或设备的属性，例如设备的名称、类型和配置信息。Data Structures是指驱动程序或设备的数据结构，例如设备的寄存器、缓存和队列。在DDI和DKI编程接口中，Properties and Data Structures是紧密相关的。驱动程序可以通过DDI和DKI编程接口来访问和管理设备的Properties and Data Structures，以便实现设备的控制和管理。 **man pages section 9** man pages section 9是Oracle Solaris操作系统提供的一种在线帮助文档，用于提供DDI和DKI编程接口的详细信息。man pages section 9包括了DDI和DKI编程接口的详细说明、示例代码和使用指南。 DDI和DKI编程接口是Oracle Solaris操作系统提供的一种设备驱动程序编程接口，用于开发和管理设备驱动程序。DDI和DKI编程接口提供了一组API，用于与操作系统和设备进行交互，并管理驱动程序和内核之间的交互。Properties and Data Structures是DDI和DKI编程接口中的重要概念，用于描述驱动程序或设备的属性和数据结构。

Structure Type

scsi_hba_tran Solaris DDI

scsi_inquiry Solaris DDI

scsi_pkt Solaris DDI

scsi_status Solaris DDI

uio DDI/DKI

Intro(9E)

Do not declare arrays of structures as the size of the structures can change between

releases. Rely only on the structure members listed in this chapter and not on unlisted

members or the position of a member in a structure.

Intro(9S)

SEE ALSO

NOTES

16 man pages section 9: DDI and DKI Properties and Data Structures • Last Revised 15 May 2001

buf – block I/O data transfer structure

#include <sys/ddi.h>

#include <sys/sunddi.h>

Architecture independent level 1 (DDI/DKI)

The buf structure is the basic data structure for block I/O transfers. Each block I/O

transfer has an associated buffer header. The header contains all the buffer control and

status information. For drivers, the buffer header pointer is the sole argument to a

block driver strategy(9E) routine. Do not depend on the size of the buf structure

when writing a driver.

A buffer header can be linked in multiple lists simultaneously. Because of this, most of

the members in the buffer header cannot be changed by the driver, even when the

buffer header is in one of the driver’s work lists.

Buffer headers are also used by the system for unbuffered or physical I/O for block

drivers. In this case, the buffer describes a portion of user data space that is locked into

memory.

Block drivers often chain block requests so that overall throughput for the device is

maximized. The av_forw and the av_back members of the buf structure can serve

as link pointers for chaining block requests.

int b_flags; /* Buffer status */

struct buf *av_forw; /* Driver work list link */

struct buf *av_back; /* Driver work list link */

size_t b_bcount; /* # of bytes to transfer */

union {

caddr_t b_addr; /* Buffer’s virtual address */

} b_un;

daddr_t b_blkno; /* Block number on device */

diskaddr_t b_lblkno; /* Expanded block number on device */

size_t b_resid; /* # of bytes not transferred */

size_t b_bufsize; /* size of allocated buffer */

int (*b_iodone)(struct buf *); /* function called */

/* by biodone */

int b_error; /* expanded error field */

void *b_private; /* "opaque" driver private area */

dev_t b_edev; /* expanded dev field */

The members of the buffer header available to test or set by a driver are as follows:

b_flags stores the buffer status and indicates to the driver whether to read or write

to the device. The driver must never clear the b_flags member. If this is done,

unpredictable results can occur including loss of disk sanity and the possible failure of

other kernel processes.

All b_flags bit values not otherwise speciﬁed above are reserved by the kernel and

may not be used.

Valid ﬂags are as follows:

buf(9S)

NAME

SYNOPSIS

INTERFACE

LEVEL

DESCRIPTION

STRUCTURE

MEMBERS

Data Structures for Drivers 19

B_BUSY Indicates the buffer is in use. The driver must not change this ﬂag

unless it allocated the buffer with getrbuf(9F) and no I/O

operation is in progress.

B_DONE Indicates the data transfer has completed. This ﬂag is read-only.

B_ERROR Indicates an I/O transfer error. It is set in conjunction with the

b_error ﬁeld. bioerror(9F) should be used in preference to

setting the B_ERROR bit.

B_PAGEIO Indicates the buffer is being used in a paged I/O request. See the

description of the b_un.b_addr ﬁeld for more information. This

ﬂag is read-only.

B_PHYS indicates the buffer header is being used for physical (direct) I/O

to a user data area. See the description of the b_un.b_addr ﬁeld

for more information. This ﬂag is read-only.

B_READ Indicates that data is to be read from the peripheral device into

main memory.

B_WRITE Indicates that the data is to be transferred from main memory to

the peripheral device. B_WRITE is a pseudo ﬂag and cannot be

directly tested; it is only detected as the NOT form of B_READ.

av_forw and av_back can be used by the driver to link the buffer into driver work

lists.

b_bcount speciﬁes the number of bytes to be transferred in both a paged and a

non-paged I/O request.

b_un.b_addr is the virtual address of the I/O request, unless B_PAGEIO is set. The

address is a kernel virtual address, unless B_PHYS is set, in which case it is a user

virtual address. If B_PAGEIO is set, b_un.b_addr contains kernel private data. Note

that either one of B_PHYS and B_PAGEIO, or neither, can be set, but not both.

b_blkno identiﬁes which logical block on the device (the device is deﬁned by the

device number) is to be accessed. The driver might have to convert this logical block

number to a physical location such as a cylinder, track, and sector of a disk. This is a

32-bit value. The driver should use b_blkno or b_lblkno, but not both.

b_lblkno identiﬁes which logical block on the device (the device is deﬁned by the

device number) is to be accessed. The driver might have to convert this logical block

number to a physical location such as a cylinder, track, and sector of a disk. This is a

64-bit value. The driver should use b_lblkno or b_blkno, but not both.

b_resid should be set to the number of bytes not transferred because of an error.

b_bufsize contains the size of the allocated buffer.

b_iodone identiﬁes a speciﬁc biodone routine to be called by the driver when the

I/O is complete.

buf(9S)

20 man pages section 9: DDI and DKI Properties and Data Structures • Last Revised 19 Sep 2002

剩余115页未读，继续阅读

weixin_40191861_zj

粉丝: 87
资源: 1万+

Oracle Solaris 9 手册：DDI 和 DKI 编程指南

Oracle Solaris 9 - man pages section 9: DDI and DKI Properties a

817-3950.pdf Oracle Solaris 9 - man pages section 9: DDI and DKI

817-3948.pdf Oracle Solaris 9 - man pages section 9: DDI and DKI

817-3949.pdf Oracle Solaris 9 - man pages section 9: DDI and DKI

Oracle Solaris 9 - man pages section 9: DDI and DKI Driver Entry

Oracle Solaris 9 - man pages section 9: DDI and DKI Kernel Funct

Oracle Solaris 9 -man pages section 9: DDI and DKI Driver Entry

Oracle Solaris 9 man pages section 9: DDI and DKI Kernel Functio

Oracle Solaris 9 - man pages section 9: DDI and DKI Properties and Data Structures

基于STM8单片机的CAT24WCxx存储器实验(I2C模拟方式).zip

最新资源