JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
man pages section 9: DDI and DKI Properties and Data Structures     Oracle Solaris 10 1/13 Information Library
search filter icon
search icon

Document Information

Preface

Introduction

Data Structures for Drivers

aio_req(9S)

buf(9S)

cb_ops(9S)

copyreq(9S)

copyresp(9S)

datab(9S)

dblk(9S)

ddi_device_acc_attr(9S)

ddi_dma_attr(9S)

ddi_dma_cookie(9S)

ddi_dmae_req(9S)

ddi_dma_lim(9S)

ddi_dma_lim_sparc(9S)

ddi_dma_lim_x86(9S)

ddi_dma_req(9S)

ddi_fm_error(9S)

ddi-forceattach(9P)

ddi_idevice_cookie(9S)

ddi-no-autodetach(9P)

ddi-no-modunload(9P)

devmap_callback_ctl(9S)

dev_ops(9S)

fmodsw(9S)

free_rtn(9S)

gld_mac_info(9S)

gld_stats(9S)

hook_nic_event(9S)

hook_pkt_event(9S)

hook_t(9S)

inquiry-device-type(9P)

inquiry-product-id(9P)

inquiry-revision-id(9P)

inquiry-vendor-id(9P)

iocblk(9S)

iovec(9S)

kstat(9S)

kstat_intr(9S)

kstat_io(9S)

kstat_named(9S)

linkblk(9S)

lso_basic_tcp_ipv4(9S)

mac_callbacks(9S)

mac_capab_lso(9S)

mac_register(9S)

mblk(9S)

modldrv(9S)

modlinkage(9S)

modlstrmod(9S)

module_info(9S)

msgb(9S)

net_inject_t(9S)

net_instance_t(9S)

no-involuntary-power-cycles(9P)

pm(9P)

pm-components(9P)

qband(9S)

qinit(9S)

queclass(9S)

queue(9S)

removable-media(9P)

scsi_address(9S)

scsi_arq_status(9S)

scsi_asc_key_strings(9S)

scsi_device(9S)

scsi_extended_sense(9S)

scsi_hba_tran(9S)

scsi_inquiry(9S)

scsi_pkt(9S)

scsi_status(9S)

streamtab(9S)

stroptions(9S)

tuple(9S)

uio(9S)

usb_bulk_request(9S)

usb_callback_flags(9S)

usb_cfg_descr(9S)

usb_client_dev_data(9S)

usb_completion_reason(9S)

usb_ctrl_request(9S)

usb_dev_descr(9S)

usb_dev_qlf_descr(9S)

usb_ep_descr(9S)

usb_if_descr(9S)

usb_intr_request(9S)

usb_isoc_request(9S)

usb_other_speed_cfg_descr(9S)

usb_request_attributes(9S)

usb_string_descr(9S)

queue

- STREAMS queue structure

Synopsis

#include <sys/stream.h>

Interface Level

Architecture independent level 1 (DDI/DKI)

Description

A STREAMS driver or module consists of two queue structures: read for upstream processing and write for downstream processing. The queue structure is the major building block of a stream.

queue Structure Members

The queue structure is defined as type queue_t. The structure can be accessed at any time from inside a STREAMS entry point associated with that queue.

struct    qinit   *q_qinfo;     /* queue processing procedure */
struct    msgb    *q_first;     /* first message in queue */
struct    msgb    *q_last;      /* last message in queue */
struct    queue   *q_next;      /* next queue in stream */
void              *q_ptr;       /* module-specific data */
size_t             q_count;     /* number of bytes on queue */
uint_t             q_flag;      /* queue state */
ssize_t            q_minpsz;    /* smallest packet OK on queue */
ssize_t            q_maxpsz;    /* largest packet OK on queue */
size_t             q_hiwat;     /* queue high water mark */
size_t             q_lowat;     /* queue low water mark */

Contstraints and restrictions on the use of q_flag and queue_t fields and the q_next values are detailed in the following sections.

q_flag Field

The q_flag field must be used only to check the following flag values.

QFULL

Queue is full.

QREADR

Queue is used for upstream (read-side) processing.

QUSE

Queue has been allocated.

QENAB

Queue has been enabled for service by qenable(9F).

QNOENB

Queue will not be scheduled for service by putq(9F).

QWANTR

Upstream processing element wants to read from queue.

QWANTW

Downstream processing element wants to write to queue.

queue_t Fields

Aside from q_ptr and q_qinfo, a module or driver must never assume that a queue_t field value will remain unchanged across calls to STREAMS entry points. In addition, many fields can change values inside a STREAMS entry point, especially if the STREAMS module or driver has perimeters that allow parallelism. See mt-streams(9F). Fields that are not documented below are private to the STREAMS framework and must not be accessed.

A STREAMS module or driver can assign any value to q_ptr. Typically q_ptr is used to point to module-specific per-queue state, allocated in open(9E) and freed in close(9E). The value or contents of q_ptr is never inspected by the STREAMS framework.

The initial values for q_minpsz, q_maxpsz, q_hiwat, and q_lowat are set using the module_info(9S) structure when mod_install(9F) is called. A STREAMS module or driver can subsequently change the values of those fields as necessary. The remaining visible fields, q_qinfo, q_first, q_last, q_next, q_count, and q_flag, must never be modified by a module or driver.

The Solaris DDI requires that STREAMS modules and drivers obey the rules described on this page. Those that do not follow the rules can cause data corruption or system instability, and might change in behavior across patches or upgrades.

q_next Restrictions

There are additional restrictions associated with the use of the q_next value. In particular, a STREAMS module or driver:

See Also

close(9E), open(9E), bcanput(9F), canput(9F), getq(9F), insq(9F), mod_install(9F), put(9F), putbq(9F), putctl(9F), putctl1(9F), putnext(9F), putq(9F), qprocsoff(9F), qprocson(9F), rmvq(9F), strqget(9F), strqset(9F), module_info(9S), msgb(9S), qinit(9S), streamtab(9S)

Writing Device Drivers

STREAMS Programming Guide