JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
man pages section 9: DDI and DKI Driver Entry Points     Oracle Solaris 11.1 Information Library
search filter icon
search icon

Document Information

Preface

Introduction

Driver Entry Points

aread(9E)

attach(9E)

audio_engine_channels(9E)

audio_engine_chinfo(9E)

audio_engine_close(9E)

audio_engine_count(9E)

audio_engine_format(9E)

audio_engine_open(9E)

audio_engine_playahead(9E)

audio_engine_qlen(9E)

audio_engine_rate(9E)

audio_engine_start(9E)

audio_engine_stop(9E)

audio_engine_sync(9E)

awrite(9E)

chpoll(9E)

close(9E)

csx_event_handler(9E)

detach(9E)

devmap(9E)

devmap_access(9E)

devmap_contextmgt(9E)

devmap_dup(9E)

devmap_map(9E)

devmap_unmap(9E)

dump(9E)

_fini(9E)

getinfo(9E)

gld(9E)

gldm_get_stats(9E)

gldm_intr(9E)

gldm_ioctl(9E)

gldm_reset(9E)

gldm_send(9E)

gldm_set_mac_addr(9E)

gldm_set_multicast(9E)

gldm_set_promiscuous(9E)

gldm_start(9E)

gldm_stop(9E)

identify(9E)

_info(9E)

_init(9E)

ioctl(9E)

ks_snapshot(9E)

ks_update(9E)

mac(9E)

mac_capab_rings(9E)

mac_group_info(9E)

mac_ring_info(9E)

mc_getcapab(9E)

mc_getprop(9E)

mc_getstat(9E)

mc_ioctl(9E)

mc_multicst(9E)

mc_propinfo(9E)

mc_setpromisc(9E)

mc_setprop(9E)

mc_start(9E)

mc_stop(9E)

mc_tx(9E)

mc_unicst(9E)

mgi_addmac(9E)

mgi_add_vlanfilter(9E)

mgi_getsriov_info(9E)

mgi_remmac(9E)

mgi_rem_vlanfliter(9E)

mgi_setmtu(9E)

mgi_start(9E)

mgi_stop(9E)

mmap(9E)

mr_gaddring(9E)

mr_gget(9E)

mr_gremring(9E)

mri_intr_disable(9E)

mri_intr_enable(9E)

mri_poll(9E)

mri_start(9E)

mri_stat(9E)

mri_stop(9E)

mri_tx(9E)

mr_rget(9E)

open(9E)

power(9E)

print(9E)

probe(9E)

prop_op(9E)

put(9E)

quiesce(9E)

read(9E)

segmap(9E)

sofop_accepted(9E)

sofop_attach_active(9E)

sofop_attach_passive(9E)

sofop_bind(9E)

sofop_connect(9E)

sofop_data_in(9E)

sofop_data_in_proc(9E)

sofop_data_out(9E)

sofop_detach(9E)

sofop_getpeername(9E)

sofop_getsockname(9E)

sofop_getsockopt(9E)

sofop_listen(9E)

sofop_notify(9E)

sofop_setsockopt(9E)

sofop_shutdown(9E)

srv(9E)

strategy(9E)

tran_abort(9E)

tran_bus_reset(9E)

tran_destroy_pkt(9E)

tran_dmafree(9E)

tran_getcap(9E)

tran_init_pkt(9E)

tran_pkt_constructor(9E)

tran_pkt_destructor(9E)

tran_quiesce(9E)

tran_reset(9E)

tran_reset_notify(9E)

tran_setcap(9E)

tran_setup_pkt(9E)

tran_start(9E)

tran_sync_pkt(9E)

tran_teardown_pkt(9E)

tran_tgt_free(9E)

tran_tgt_init(9E)

tran_tgt_probe(9E)

tran_unquiesce(9E)

write(9E)

srv

- service queued messages

Synopsis

#include <sys/types.h>
#include <sys/stream.h>
#include <sys/stropts.h>
#include <sys/ddi.h>
#include <sys/sunddi.h>

intprefixrsrv(queue_t *q/* read side */
intprefixwsrv(queue_t *q/* write side */

Interface Level

Architecture independent level 1 (DDI/DKI). This entry point is required for STREAMS.

ARGUMENTS

q

Pointer to the queue(9S) structure.

Description

The optional service srv() routine may be included in a STREAMS module or driver for many possible reasons, including:

A message is first passed to a module's or driver's put(9E) routine, which may or may not do some processing. It must then either:

Once a message has been enqueued, the STREAMS scheduler controls the service routine's invocation. The scheduler calls the service routines in FIFO order. The scheduler cannot guarantee a maximum delay srv() routine to be called except that it will happen before any user level process are run.

Every stream component (stream head, module or driver) has limit values it uses to implement flow control. Each component should check the tunable high and low water marks to stop and restart the flow of message processing. Flow control limits apply only between two adjacent components with srv() routines.

STREAMS messages can be defined to have up to 256 different priorities to support requirements for multiple bands of data flow. At a minimum, a stream must distinguish between normal (priority zero) messages and high priority messages (such as M_IOCACK). High priority messages are always placed at the head of the srv() routine's queue, after any other enqueued high priority messages. Next are messages from all included priority bands, which are enqueued in decreasing order of priority. Each priority band has its own flow control limits. If a flow controlled band is stopped, all lower priority bands are also stopped.

Once the STREAMS scheduler calls a srv() routine, it must process all messages on its queue. The following steps are general guidelines for processing messages. Keep in mind that many of the details of how a srv() routine should be written depend of the implementation, the direction of flow (upstream or downstream), and whether it is for a module or a driver.

  1. Use getq(9F) to get the next enqueued message.

  2. If the message is high priority, process (if appropriate) and pass to the next stream component with putnext(9F).

  3. If it is not a high priority message (and therefore subject to flow control), attempt to send it to the next stream component with a srv() routine. Use bcanputnext(9F) to determine if this can be done.

  4. If the message cannot be passed, put it back on the queue with putbq(9F). If it can be passed, process (if appropriate) and pass with putnext().

Return Values

Ignored.

See Also

put(9E), bcanput(9F), bcanputnext(9F), canput(9F), canputnext(9F), getq(9F), nulldev(9F), putbq(9F), putnext(9F), putq(9F), qinit(9S), queue(9S)

Writing Device Drivers

STREAMS Programming Guide

Warnings

Each stream module must specify a read and a write service srv() routine. If a service routine is not needed (because the put() routine processes all messages), a NULL pointer should be placed in module's qinit(9S) structure. Do not use nulldev(9F) instead of the NULL pointer. Use ofnulldev(9F) for a srv() routine can result in flow control errors.