IOCTL

ioctl:
https://elixir.bootlin.com/linux/v5.7.2/source/arch/alpha/include/uapi/asm/ioctl.h#L49.

If you are adding new ioctl’s to the kernel, you should use the _IOmacros defined in <linux/ioctl.h>:

‘Write’ and ‘read’ are from the user’s point of view, just like the
system calls ‘write’ and ‘read’.

_IO an ioctl with no parameters
_IOW an ioctl with write parameters (copy_from_user)
_IOR an ioctl with read parameters (copy_to_user)
_IOWR an ioctl with both write and read parameters.

Following this 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 this convention is used to define the ioctl numbers.

(5) When following the convention, the driver code can use generic code to copy the parameters between user and kernel space.

To decode a hex IOCTL code:

Most architectures use this generic format, but check
include/ARCH/ioctl.h for specifics, e.g. powerpc
uses 3 bits to encode read/write and 13 bits for size.

bits meaning
31-30
00 - no parameters: uses _IO macro
10 - read: _IOR
01 - write: _IOW
11 - read/write: _IOWR

29-16
size of arguments

15-8
ascii character supposedly
unique to each driver

7-0
function #

So for example 0x82187201 is a read with arg length of 0x218,
character ‘r’ function 1. Grepping the source reveals this is:

#define VFAT_IOCTL_READDIR_BOTH _IOR(‘r’, 1, struct dirent [2])

引用文本内容摘自：KERNEL\linux-5.2.13\Documentation\ioctl