1 .\" $NetBSD: ioctl.9,v 1.26 2008/11/12 12:35:54 ad Exp $
3 .\" Copyright (c) 1999 The NetBSD Foundation, Inc.
4 .\" All rights reserved.
6 .\" This code is derived from software contributed to The NetBSD Foundation
7 .\" by Heiko W.Rupp <hwr@pilhuhn.de>
9 .\" Redistribution and use in source and binary forms, with or without
10 .\" modification, are permitted provided that the following conditions
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.
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.
35 .Nd "how to implement a new ioctl call to access device drivers"
40 .Fn ioctl "int" "unsigned long" "..."
43 are internally defined as
44 .Bl -tag -width define
45 .It #define FOOIOCTL fun(t,n,pt)
48 where the different variables and functions are:
49 .Bl -tag -width FOOIOCTL
51 the name which will later be given in the
53 system call as second argument, e.g.,
54 .Dl ioctl(s, FOOIOCTL, ...) .
56 a macro which can be one of
59 the call is a simple message to the kernel by itself.
60 It does not copy anything into the kernel, nor does it want anything back.
62 the call only reads parameters from the kernel and does not
65 the call only writes parameters to the kernel, but does not want anything
68 the call writes data to the kernel and wants information back.
71 This integer describes to which subsystem the ioctl applies.
74 .Bl -tag -width xxxxx -compact
76 pulse-per-second interface
84 Advanced Power Management (hpcmips, i386, sparc), see
87 ADB devices (mac68k, macppc)
95 Bluetooth HCI sockets, see
98 Bluetooth Hub Control, see
101 Bluetooth SCO audio driver, see
114 clock devices (amiga, atari, hp300, x68k)
124 Sun-compatible framebuffers
132 grf devices (amiga, atari, hp300, mac68k, x68k)
145 ISA joystick interface
147 Sun-compatible (and other) keyboards
153 mouse devices (atari)
157 virtual console device (arm32)
161 OpenPROM and OpenFirmware
165 parallel port (amiga, x68k)
169 printer/plotter interface (hp300)
176 pmax graphics devices
182 the routing subsystem
194 SCSI disks (arc, hp300, pmax)
196 watchdog devices (sh3)
214 view device (amiga, atari)
226 ite devices (amiga, atari, x68k)
231 This numbers the ioctl within the group.
232 There may be only one
236 This is an unsigned 8 bit number.
238 This specifies the type of the passed parameter.
239 This one gets internally transformed to the size of the parameter, so
240 for example, if you want to pass a structure, then you have to specify that
241 structure and not a pointer to it or sizeof(struct foo)
244 In order for the new ioctl to be known to the system it is installed
245 in either \*[Lt]sys/ioctl.h\*[Gt] or one of the files that are reached from
246 \*[Lt]sys/ioctl.h\*[Gt].
248 .Bd -literal -offset indent
249 #define FOOIOCTL _IOWR('i', 23, int)
252 error = ioctl(s, FOOICTL, \*[Am]a);
255 Within the ioctl()-routine of the driver, it can be then accessed like
256 .Bd -literal -offset indent
257 driver_ioctl(..., u_long cmd, void *data)
263 int *a = (int *)data;
264 printf(" Value passed: %d\en", *a);
270 Note that if you for example try to read information from an ethernet
271 driver where the name of the card is included in the third argument
272 (e.g., ioctl(s, READFROMETH, struct ifreq *)), then you have to use
273 the _IOWR() form not the _IOR(), as passing the name of the card to the
274 kernel already consists of writing data.
276 All ioctl() routines should return either 0 or a defined error code.
277 The use of magic numbers such as -1, to indicate that a given ioctl
278 code was not handled is strongly discouraged.
279 The value -1 coincides with the historic value for
281 which was shown to produce user space code that never returned from
286 are not handled by a given routine, the pseudo error value
290 indicates that no error occurred during processing (it did not fail),
291 but neither was anything processed (it did not succeed).
292 This supersedes the use of either
294 (which is an explicit failure) or -1 (which has no contextual meaning)
297 will get passed directly back to user space and bypass any further
298 processing by other ioctl layers.
299 Only code that wishes to suppress possible further processing of an
300 ioctl code (e.g., the tty line discipline code) should return
302 All other code should return
304 even if it knows that no other layers will be called upon.
310 then it will there be changed to
312 to be returned to user space, thereby providing the proper error
313 notification to the application.