1srv(9E)                       Driver Entry Points                      srv(9E)
2
3
4

NAME

6       srv - service queued messages
7

SYNOPSIS

9       #include <sys/types.h>
10       #include <sys/stream.h>
11       #include <sys/stropts.h>
12       #include <sys/ddi.h>
13       #include <sys/sunddi.h>
14
15
16
17       intprefixrsrv(queue_t *q/* read side */
18
19
20       intprefixwsrv(queue_t *q/* write side */
21
22

INTERFACE LEVEL

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

ARGUMENTS

28       q    Pointer to the queue(9S) structure.
29
30

DESCRIPTION

32       The optional service srv() routine may be included in a STREAMS  module
33       or driver for many possible reasons, including:
34
35           o      to  provide  greater  control over the flow of messages in a
36                  stream;
37
38           o      to make it possible to defer the processing of some messages
39                  to avoid depleting system resources;
40
41           o      to  combine  small messages into larger ones, or break large
42                  messages into smaller ones;
43
44           o      to recover from resource allocation failure. A  module's  or
45                  driver's  put(9E) routine can test for the availability of a
46                  resource, and if it is not available,  enqueue  the  message
47                  for later processing by the srv() routine.
48
49
50       A  message  is  first passed to a module's or driver's put(9E) routine,
51       which may or may not do some processing. It must then either:
52
53           o      Pass the message to the  next  stream  component  with  put‐
54                  next(9F).
55
56           o      If  a  srv() routine has been included, it may call putq(9F)
57                  to place the message on the queue.
58
59
60       Once a message has been enqueued, the STREAMS  scheduler  controls  the
61       service  routine's invocation. The scheduler calls the service routines
62       in FIFO order. The scheduler cannot guarantee  a  maximum  delay  srv()
63       routine  to  be called except that it will happen before any user level
64       process are run.
65
66
67       Every stream component (stream head, module or driver) has limit values
68       it uses to implement flow control. Each component should check the tun‐
69       able high and low water marks to stop and restart the flow  of  message
70       processing.  Flow control limits apply only between two adjacent compo‐
71       nents with srv() routines.
72
73
74       STREAMS  messages can be defined to have up to 256 different priorities
75       to  support requirements for multiple bands of data flow. At a minimum,
76       a stream must distinguish between normal (priority zero)  messages  and
77       high  priority  messages (such as M_IOCACK). High priority messages are
78       always placed at the head of the srv() routine's queue, after any other
79       enqueued  high  priority  messages. Next are messages from all included
80       priority bands, which are enqueued in  decreasing  order  of  priority.
81       Each  priority  band  has  its  own flow control limits. If a flow con‐
82       trolled band is stopped, all lower priority bands are also stopped.
83
84
85       Once the STREAMS scheduler calls a srv() routine, it must  process  all
86       messages  on  its queue. The following steps are general guidelines for
87       processing messages. Keep in mind that many of the  details  of  how  a
88       srv()  routine  should  be  written  depend  of the implementation, the
89       direction of flow (upstream or downstream), and whether  it  is  for  a
90       module or a driver.
91
92           1.     Use getq(9F) to get the next enqueued message.
93
94           2.     If  the  message  is high priority, process (if appropriate)
95                  and pass to the next stream component with putnext(9F).
96
97           3.     If it is not a high priority message (and therefore  subject
98                  to flow control), attempt to send it to the next stream com‐
99                  ponent with a srv() routine. Use bcanputnext(9F)  to  deter‐
100                  mine if this can be done.
101
102           4.     If  the  message  cannot be passed, put it back on the queue
103                  with putbq(9F). If it can be passed, process  (if  appropri‐
104                  ate) and pass with putnext().
105

RETURN VALUES

107       Ignored.
108

SEE ALSO

110       put(9E),   bcanput(9F),  bcanputnext(9F),  canput(9F),  canputnext(9F),
111       getq(9F), nulldev(9F),  putbq(9F),  putnext(9F),  putq(9F),  qinit(9S),
112       queue(9S)
113
114
115       Writing Device Drivers
116
117
118       STREAMS Programming Guide
119

WARNINGS

121       Each  stream  module must specify a read and a write service srv() rou‐
122       tine. If a service routine is not needed  (because  the  put()  routine
123       processes  all  messages),  a NULL pointer should be placed in module's
124       qinit(9S) structure.  Do  not  use  nulldev(9F)  instead  of  the  NULL
125       pointer. Use  ofnulldev(9F) for a srv() routine can result in flow con‐
126       trol errors.
127
128
129
130SunOS 5.11                        12 Nov 1992                          srv(9E)
Impressum