1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
|
Ioctl Numbers
18 Feb 1998
Michael Chastain
<mec@shout.net>
If you are adding new ioctl's to the kernel, you should use the _IO
macros defined in <linux/ioctl.h>:
_IO an ioctl with no parameters
_IOW an ioctl with write parameters (from user's point of view)
_IOR an ioctl with read parameters (from user's point of view)
_IOWR an ioctl with both write and read parameters.
'Write' and 'read' are from the user's point of view. This is like the
system calls 'write' and 'read'. For example, a SET_FOO ioctl would be
_IOW, although the kernel would actually read data from user space; a
GET_FOO ioctl would be _IOR, although the kernel would actually write
data to user space.
The first argument to _IO, _IOW, _IOR, or _IOWR is an identifying letter
or number from the table below. If you are writing a driver for a new
device and need a letter, pick an unused letter. You can register the
letter by patching this file and submitting the patch to Linus Torvalds.
Or you can e-mail me at <mec@shout.net> and I'll register one for you.
The second argument to _IO, _IOW, _IOR, or _IOWR is a sequence number
to distinguish ioctls from each other. The third argument is the size
of the structure going into the kernel or coming out of the kernel.
Some devices use their major number as the identifier; this is not
recommended. Some devices are even more irregular and don't follow
the convention at all.
Following the convention is good because:
(1) Keeping the ioctl's globally unique helps error checking:
if a program calls an ioctl on the wrong device, it will get an
error rather than some unexpected behaviour.
(2) The 'strace' build procedure automatically finds ioctl numbers
defined with _IO, _IOW, _IOR, or _IOWR.
(3) 'strace' can decode numbers back into useful names when the
numbers are unique.
(4) People looking for ioctls can grep for them more easily when
the convention is used to define the ioctl numbers.
(5) When following the convention, the driver code can use generic
code to call verify_area to validate parameters.
This table lists ioctls visible from user land for Linux/i386. It is
current to Linux 2.1.15.
Code Seq# Include File Comments
========================================================
0x00 01-02 linux/fs.h conflict!
0x00 01-04 scsi/scsi_ioctl.h conflict!
0x02 all linux/fd.h
0x03 all linux/hdreg.h
0x04 all linux/umsdos_fs.h
0x06 all linux/lp.h
0x09 all linux/md.h
0x12 all linux/fs.h
0x20 all linux/cm206.h
0x22 all scsi/sg.h
'A' all linux/apm_bios.h
'C' all linux/soundcard.h
'F' all linux/fb.h
'I' all linux/isdn.h
'K' all linux/kd.h
'L' all linux/loop.h
'M' all linux/soundcard.h
'P' all linux/soundcard.h
'Q' all linux/soundcard.h
'R' all linux/random.h
'S' 00-7F linux/cdrom.h
'S' 80-81 scsi/scsi_ioctl.h
'S' 82-FF scsi/scsi.h
'T' all linux/soundcard.h conflict!
'T' all asm-i386/ioctls.h conflict!
'V' all linux/vt.h
'W' 00-1F linux/router.h conflict [Please reallocate]
'W' 00-1F linux/watchdog.h
'W' 20-27 linux/octal-relay.h in development
'W' 28-2F linux/iso16-relay.h in development
'Y' all linux/cyclades.h
'a' all various, see http://lrcwww.epfl.ch/linux-atm/magic.html
'b' 00-FF bit3 vme host bridge in development:
<mailto:natalia@nikhefk.nikhef.nl>
'c' all linux/comstats.h
'f' all linux/ext2_fs.h
'j' 00-3F linux/joystick.h
'k' all asm-sparc/kbio.h, asm-sparc64/kbio.h
'l' 00-3F linux/tcfs_fs.h in development:
<http://mikonos.dia.unisa.it/tcfs>
'm' all linux/mtio.h conflict!
'm' all linux/soundcard.h conflict!
'n' all linux/ncp_fs.h
'p' 00-3F linux/mc146818rtc.h
'p' 40-7F linux/nvram.h
'p' 80-9F user-space parport in development:
<tim@cyberelk.demon.co.uk>
'r' all linux/msdos_fs.h
's' all linux/cdk.h
't' 00-7F linux/if_ppp.h
't' 80-8F linux/isdn_ppp.h
'u' all linux/smb_fs.h
'v' all linux/ext2_fs.h
'w' all CERN SCI driver in development
'z' 00-3F CAN bus card in development:
<mailto:hdstich@connectu.ulm.circular.de>
'z' 40-7F CAN bas card in development:
<mailto:oe@port.de>
0x89 00-0F asm-i386/sockios.h
0x89 10-DF linux/sockios.h
0x89 E0-EF linux/sockios.h SIOCPROTOPRIVATE range
0x89 F0-FF linux/sockios.h SIOCDEVPRIVATE range
0x8B all linux/wireless.h
0x8C 00-3F WiNRADiO driver in development:
<http://www.proximity.com.au/~brian/winradio/>
0x90 00 linux/sbpcd.h
0x93 60-7F linux/auto_fs.h
0x99 00-0F 537-Addinboard driver in development:
<mailto:b.kohl@ipn-b.comlink.apc.org>
0xA0 all Small Device Project in development:
<mailto:khollis@northwest.com>
0xA3 80-8F Port ACL in development:
<mailto:tlewis@mindspring.com>
0xA3 90-9F DoubleTalk driver in development:
<mailto:jrv@vanzandt.mv.com>
0xAB 00-06 Network block device
|
