]> CyberLeo.Net >> Repos - FreeBSD/stable/10.git/blob - share/man/man4/pass.4
MFC r317775:
[FreeBSD/stable/10.git] / share / man / man4 / pass.4
1 .\"
2 .\" Copyright (c) 1998, 1999 Kenneth D. Merry.
3 .\" All rights reserved.
4 .\"
5 .\" Redistribution and use in source and binary forms, with or without
6 .\" modification, are permitted provided that the following conditions
7 .\" are met:
8 .\" 1. Redistributions of source code must retain the above copyright
9 .\"    notice, this list of conditions and the following disclaimer.
10 .\" 2. Redistributions in binary form must reproduce the above copyright
11 .\"    notice, this list of conditions and the following disclaimer in the
12 .\"    documentation and/or other materials provided with the distribution.
13 .\" 3. The name of the author may not be used to endorse or promote products
14 .\"    derived from this software without specific prior written permission.
15 .\"
16 .\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
17 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
18 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
19 .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
20 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
21 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
22 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
23 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
24 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
25 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
26 .\" SUCH DAMAGE.
27 .\"
28 .\" $FreeBSD$
29 .\"
30 .Dd May 3, 2017
31 .Dt PASS 4
32 .Os
33 .Sh NAME
34 .Nm pass
35 .Nd CAM application passthrough driver
36 .Sh SYNOPSIS
37 .Cd device pass
38 .Sh DESCRIPTION
39 The
40 .Nm
41 driver provides a way for userland applications to issue CAM CCBs to the
42 kernel.
43 .Pp
44 Since the
45 .Nm
46 driver allows direct access to the CAM subsystem, system administrators
47 should exercise caution when granting access to this driver.
48 If used
49 improperly, this driver can allow userland applications to crash a machine
50 or cause data loss.
51 .Pp
52 The
53 .Nm
54 driver attaches to every
55 .Tn SCSI
56 and
57 .Tn ATA
58 device found in the system.
59 Since it attaches to every device, it provides a generic means of accessing
60 .Tn SCSI
61 and
62 .Tn ATA
63 devices, and allows the user to access devices which have no
64 "standard" peripheral driver associated with them.
65 .Sh KERNEL CONFIGURATION
66 It is only necessary to configure one
67 .Nm
68 device in the kernel;
69 .Nm
70 devices are automatically allocated as
71 .Tn SCSI
72 and
73 .Tn ATA
74 devices are found.
75 .Sh IOCTLS
76 .Bl -tag -width 5n
77 .It CAMIOCOMMAND union ccb *
78 This ioctl takes most kinds of CAM CCBs and passes them through to the CAM
79 transport layer for action.
80 Note that some CCB types are not allowed
81 through the passthrough device, and must be sent through the
82 .Xr xpt 4
83 device instead.
84 Some examples of xpt-only CCBs are XPT_SCAN_BUS,
85 XPT_DEV_MATCH, XPT_RESET_BUS, XPT_SCAN_LUN, XPT_ENG_INQ, and XPT_ENG_EXEC.
86 These CCB types have various attributes that make it illogical or
87 impossible to service them through the passthrough interface.
88 .Pp
89 If the user would like the kernel to do error recovery, the
90 .Dv CAM_PASS_ERR_RECOVER
91 flag must be set on the CCB, and the retry_count field set to the number
92 of retries.
93 .It CAMGETPASSTHRU union ccb *
94 This ioctl takes an XPT_GDEVLIST CCB, and returns the passthrough device
95 corresponding to the device in question.
96 Although this ioctl is available through the
97 .Nm
98 driver, it is of limited use, since the caller must already know that
99 the device in question is a passthrough device if they are issuing this
100 ioctl.
101 It is probably more useful to issue this ioctl through the
102 .Xr xpt 4
103 device.
104 .It CAMIOQUEUE union ccb *
105 Queue a CCB to the
106 .Xr pass 4
107 driver to be executed asynchronously.
108 The caller may use
109 .Xr select 2 ,
110 .Xr poll 2 
111 or
112 .Xr kevent 2
113 to receive notification when the CCB has completed.
114 .Pp
115 This ioctl takes most CAM CCBs, but some CCB types are not allowed through
116 the pass device, and must be sent through the
117 .Xr xpt 4
118 device instead.
119 Some examples of xpt-only CCBs are XPT_SCAN_BUS,
120 XPT_DEV_MATCH, XPT_RESET_BUS, XPT_SCAN_LUN, XPT_ENG_INQ, and XPT_ENG_EXEC.
121 These CCB types have various attributes that make it illogical or
122 impossible to service them through the passthrough interface.
123 .Pp
124 Although the
125 .Dv CAMIOQUEUE
126 ioctl is not defined to take an argument, it does require a
127 pointer to a union ccb.
128 It is not defined to take an argument to avoid an extra malloc and copy 
129 inside the generic 
130 .Xr ioctl 2
131 handler.
132 .pp
133 The completed CCB will be returned via the
134 .Dv CAMIOGET
135 ioctl.
136 An error will only be returned from the
137 .Dv CAMIOQUEUE
138 ioctl if there is an error allocating memory for the request or copying
139 memory from userland.
140 All other errors will be reported as standard CAM CCB status errors.
141 Since the CCB is not copied back to the user process from the pass driver
142 in the
143 .Dv CAMIOQUEUE
144 ioctl, the user's passed-in CCB will not be modfied.
145 This is the case even with immediate CCBs.
146 Instead, the completed CCB must be retrieved via the
147 .Dv CAMIOGET
148 ioctl and the status examined.
149 .Pp
150 Multiple CCBs may be queued via the
151 .Dv CAMIOQUEUE
152 ioctl at any given time, and they may complete in a different order than
153 the order that they were submitted.
154 The caller must take steps to identify CCBs that are queued and completed.
155 The
156 .Dv periph_priv
157 structure inside struct ccb_hdr is available for userland use with the
158 .Dv CAMIOQUEUE
159 and
160 .Dv CAMIOGET
161 ioctls, and will be preserved across calls.
162 Also, the periph_links linked list pointers inside struct ccb_hdr are
163 available for userland use with the
164 .Dv CAMIOQUEUE
165 and
166 .Dv CAMIOGET
167 ioctls and will be preserved across calls.
168 .Pp
169 If the user would like the kernel to do error recovery, the
170 .Dv CAM_PASS_ERR_RECOVER
171 flag must be set on the CCB, and the retry_count field set to the number
172 of retries.
173 .It CAMIOGET union ccb *
174 Retrieve completed CAM CCBs queued via the
175 .Dv CAMIOQUEUE
176 ioctl.
177 An error will only be returned from the
178 .Dv CAMIOGET
179 ioctl if the
180 .Xr pass 4
181 driver fails to copy data to the user process or if there are no completed
182 CCBs available to retrieve.
183 If no CCBs are available to retrieve,
184 errno will be set to 
185 .Dv ENOENT .
186 .Pp
187 All other errors will be reported as standard CAM CCB status errors.
188 .Pp
189 Although the
190 .Dv CAMIOGET
191 ioctl is not defined to take an argument, it does require a
192 pointer to a union ccb.
193 It is not defined to take an argument to avoid an extra malloc and copy 
194 inside the generic 
195 .Xr ioctl 2
196 handler.
197 .Pp
198 The pass driver will report via
199 .Xr select 2 ,
200 .Xr poll 2 
201 or
202 .Xr kevent 2
203 when a CCB has completed.
204 One CCB may be retrieved per
205 .Dv CAMIOGET
206 call.
207 CCBs may be returned in an order different than the order they were
208 submitted.
209 So the caller should use the
210 .Dv periph_priv
211 area inside the CCB header to store pointers to identifying information.
212 .El
213 .Sh FILES
214 .Bl -tag -width /dev/passn -compact
215 .It Pa /dev/pass Ns Ar n
216 Character device nodes for the
217 .Nm
218 driver.
219 There should be one of these for each device accessed through the
220 CAM subsystem.
221 .El
222 .Sh DIAGNOSTICS
223 None.
224 .Sh SEE ALSO
225 .Xr kqueue 2 ,
226 .Xr poll 2 ,
227 .Xr select 2 ,
228 .Xr cam 3 ,
229 .Xr cam 4 ,
230 .Xr cam_cdbparse 3 ,
231 .Xr cd 4 ,
232 .Xr ctl 4 ,
233 .Xr da 4 ,
234 .Xr sa 4 ,
235 .Xr xpt 4 ,
236 .Xr camcontrol 8 ,
237 .Xr camdd 8
238 .Sh HISTORY
239 The CAM passthrough driver first appeared in
240 .Fx 3.0 .
241 .Sh AUTHORS
242 .An Kenneth Merry Aq ken@FreeBSD.org