xref: /netbsd-src/share/man/man9/ioctl.9 (revision b1c86f5f087524e68db12794ee9c3e3da1ab17a0)
1.\" $NetBSD: ioctl.9,v 1.28 2010/05/14 18:39:05 joerg Exp $
2.\"
3.\" Copyright (c) 1999  The NetBSD Foundation, Inc.
4.\" All rights reserved.
5.\"
6.\" This code is derived from software contributed to The NetBSD Foundation
7.\" by Heiko W.Rupp <hwr@pilhuhn.de>
8.\"
9.\" Redistribution and use in source and binary forms, with or without
10.\" modification, are permitted provided that the following conditions
11.\" are met:
12.\" 1. Redistributions of source code must retain the above copyright
13.\"    notice, this list of conditions and the following disclaimer.
14.\" 2. Redistributions in binary form must reproduce the above copyright
15.\"    notice, this list of conditions and the following disclaimer in the
16.\"    documentation and/or other materials provided with the distribution.
17.\"
18.\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
19.\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
20.\" TO, THE  IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
21.\" PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
22.\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
23.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
24.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
25.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
26.\" CONTRACT, STRICT  LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
27.\" ARISING IN ANY WAY  OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
28.\" POSSIBILITY OF SUCH DAMAGE.
29.\"
30.Dd December 7, 2001
31.Dt IOCTL 9
32.Os
33.Sh NAME
34.Nm ioctl
35.Nd "how to implement a new ioctl call to access device drivers"
36.Sh SYNOPSIS
37.In sys/ioctl.h
38.In sys/ioccom.h
39.Ft int
40.Fn ioctl "int" "unsigned long" "..."
41.Sh DESCRIPTION
42.Nm
43are internally defined as
44.Bl -tag -width define
45.It #define FOOIOCTL   fun(t,n,pt)
46.El
47.Pp
48where the different variables and functions are:
49.Bl -tag -width FOOIOCTL
50.It Cm FOOIOCTL
51the name which will later be given in the
52.Xr ioctl 2
53system call as second argument, e.g.,
54.Dl ioctl(s, FOOIOCTL, ...) .
55.It Fn fun
56a macro which can be one of
57.Bl -tag -width _IOWR
58.It _IO
59the call is a simple message to the kernel by itself.
60It does not copy anything into the kernel, nor does it want anything back.
61.It _IOR
62the call only reads parameters from the kernel and does not
63pass any to it
64.It _IOW
65the call only writes parameters to the kernel, but does not want anything
66back
67.It _IOWR
68the call writes data to the kernel and wants information back.
69.El
70.It Ar t
71This integer describes to which subsystem the ioctl applies.
72.Ar t
73can be one of
74.Bl -tag -width xxxxx -compact
75.It '1'
76pulse-per-second interface
77.It '4'
78.Xr isdn 4
79.It 'a'
80ISO networking
81.It 'A'
82ac devices (hp300)
83.It 'A'
84Advanced Power Management (hpcmips, i386, sparc), see
85.Xr apm 4
86.It 'A'
87ADB devices (mac68k, macppc)
88.It 'A'
89.Xr audio 4
90.It 'A'
91.Xr isdntel 4
92.It 'b'
93.Xr \&tb 4
94.It 'b'
95Bluetooth HCI sockets, see
96.Xr bluetooth 4
97.It 'b'
98Bluetooth Hub Control, see
99.Xr bthub 4
100.It 'b'
101Bluetooth SCO audio driver, see
102.Xr btsco 4
103.It 'B'
104bell device (x68k)
105.It 'B'
106.Xr bpf 4
107.It 'c'
108coda
109.It 'c'
110.Xr \&cd 4
111.It 'c'
112.Xr \&ch 4
113.It 'C'
114clock devices (amiga, atari, hp300, x68k)
115.It 'C'
116.Xr isdnctl 4
117.It 'd'
118the disk subsystem
119.It 'E'
120.Xr envsys 4
121.It 'f'
122files
123.It 'F'
124Sun-compatible framebuffers
125.It 'F'
126.Xr ccd 4
127and
128.Xr vnd 4
129.It 'g'
130qdss framebuffers
131.It 'G'
132grf devices (amiga, atari, hp300, mac68k, x68k)
133.It 'h'
134HIL devices (hp300)
135.It 'H'
136HIL devices (hp300)
137.It 'H'
138HPc framebuffers
139.It 'i'
140a (pseudo) interface
141.It 'I'
142.Xr ite 4
143(mac68k)
144.It 'J'
145ISA joystick interface
146.It 'k'
147Sun-compatible (and other) keyboards
148.It 'l'
149leo devices (atari)
150.It 'm'
151.Xr mtio 4
152.It 'M'
153mouse devices (atari)
154.It 'M'
155.Xr mlx 4
156.It 'n'
157virtual console device (arm32)
158.It 'n'
159SMB networking
160.It 'O'
161OpenPROM and OpenFirmware
162.It 'p'
163power control (x68k)
164.It 'P'
165parallel port (amiga, x68k)
166.It 'P'
167profiling (arm32)
168.It 'P'
169printer/plotter interface (hp300)
170.It 'P'
171.Xr magma 4
172bpp (sparc)
173.It 'q'
174.Xr altq 9
175.It 'q'
176pmax graphics devices
177.It 'Q'
178.Xr altq 9
179.It 'Q'
180raw SCSI commands
181.It 'r'
182the routing subsystem
183.It 'r'
184.Xr \&md 4
185.It 'R'
186.Xr isdnbchan 4
187.It 'R'
188.Xr rnd 4
189.It 's'
190the socket layer
191.It 's'
192satlink devices
193.It 'S'
194SCSI disks (arc, hp300, pmax)
195.It 'S'
196watchdog devices (sh3)
197.It 'S'
198ISA speaker devices
199.It 'S'
200stic devices
201.It 'S'
202scanners
203.It 't'
204the tty layer
205.It 'u'
206user defined ???
207.It 'U'
208scsibus (see
209.Xr scsi 4 )
210.It 'v'
211Sun-compatible
212.Dq firm events
213.It 'V'
214view device (amiga, atari)
215.It 'V'
216sram device (x68k)
217.It 'w'
218watchdog devices
219.It 'W'
220wt devices
221.It 'W'
222wscons devices
223.It 'x'
224bt8xx devices
225.It 'Z'
226ite devices (amiga, atari, x68k)
227.It 'Z'
228passthrough ioctls
229.El
230.It Ar n
231This numbers the ioctl within the group.
232There may be only one
233.Ar n
234for a given
235.Ar t .
236This is an unsigned 8 bit number.
237.It Ar pt
238This specifies the type of the passed parameter.
239This one gets internally transformed to the size of the parameter, so
240for example, if you want to pass a structure, then you have to specify that
241structure and not a pointer to it or sizeof(struct foo)
242.El
243.Pp
244In order for the new ioctl to be known to the system it is installed
245in either \*[Lt]sys/ioctl.h\*[Gt] or one of the files that are reached from
246\*[Lt]sys/ioctl.h\*[Gt].
247.Sh RETURN VALUES
248All ioctl() routines should return either 0 or a defined error code.
249The use of magic numbers such as -1, to indicate that a given ioctl
250code was not handled is strongly discouraged.
251The value -1 coincides with the historic value for
252.Cm ERESTART
253which was shown to produce user space code that never returned from
254a call to
255.Xr ioctl 2 .
256.Pp
257For ioctl codes that
258are not handled by a given routine, the pseudo error value
259.Cm EPASSTHROUGH
260is provided.
261.Cm EPASSTHROUGH
262indicates that no error occurred during processing (it did not fail),
263but neither was anything processed (it did not succeed).
264This supersedes the use of either
265.Cm ENOTTY
266(which is an explicit failure) or -1 (which has no contextual meaning)
267as a return value.
268.Cm ENOTTY
269will get passed directly back to user space and bypass any further
270processing by other ioctl layers.
271Only code that wishes to suppress possible further processing of an
272ioctl code (e.g., the tty line discipline code) should return
273.Cm ENOTTY .
274All other code should return
275.Cm EPASSTHROUGH ,
276even if it knows that no other layers will be called upon.
277.Pp
278If the value
279.Cm EPASSTHROUGH
280is returned to
281.Fn sys_ioctl ,
282then it will there be changed to
283.Cm ENOTTY
284to be returned to user space, thereby providing the proper error
285notification to the application.
286.Sh EXAMPLES
287.Bd -literal -offset indent
288#define	FOOIOCTL	_IOWR('i', 23, int)
289
290int a = 3;
291error = ioctl(s, FOOICTL, \*[Am]a);
292.Ed
293.Pp
294Within the ioctl()-routine of the driver, it can be then accessed like
295.Bd -literal -offset indent
296driver_ioctl(..., u_long cmd, void *data)
297{
298	...
299	switch (cmd) {
300
301	case FOOIOCTL:
302		int *a = (int *)data;
303		printf(" Value passed: %d\en", *a);
304		break;
305	}
306}
307.Ed
308.Sh NOTES
309Note that if you for example try to read information from an ethernet
310driver where the name of the card is included in the third argument
311(e.g., ioctl(s, READFROMETH, struct ifreq *)), then you have to use
312the _IOWR() form not the _IOR(), as passing the name of the card to the
313kernel already consists of writing data.
314.Sh SEE ALSO
315.Xr ioctl 2
316