Device-independent request codes are sometimes used to give userspace access to kernel functions which are only used by core system software or still under development.
But user code may need to communicate directly with devices; for instance, an administrator might configure the media type on an Ethernet interface.
Modern operating systems support diverse devices, many of which offer a large collection of facilities.
For example, on Win32 systems, ioctl calls can communicate with USB devices, or they can discover drive-geometry information of the attached storage-devices.
On OpenBSD and NetBSD, ioctl is used by the bio(4) pseudo-device driver and the bioctl utility to implement RAID volume management in a unified vendor-agnostic interface similar to ifconfig.
However, when the envsys framework was redesigned in 2007 around proplib, the system call remained as ioctl, and the message was removed.
The mnemonic ENOTTY (traditionally associated with the textual message "Not a typewriter") derives from the earliest systems that incorporated an ioctl call, where only the teletype (tty) device raised this error.
Though the symbolic mnemonic is fixed by compatibility requirements, some modern systems more helpfully render a more general message such as "Inappropriate device control operation" (or a localization thereof).
The normal read and write calls on a serial port receive and send data bytes.
Netlink is a socket-like mechanism for inter-process communication (IPC), designed to be a more flexible successor to ioctl.
However, by providing a place for developers to "stash" bits and pieces of kernel programming interfaces, ioctl calls complicate the overall user-to-kernel API.
This has led to the difficult-in-practice requirement that all drivers, which now reside in ring 0 as well, must uphold the same level of security as the kernel core.
Because the handler for an ioctl call also resides directly in ring 0, the input from userspace should be validated just as carefully.
As vulnerabilities in device drivers can be exploited by local users, e.g. by passing invalid buffers to ioctl calls.
Varying fixes for this have been created, with the goal of achieving an equivalent to the former security, while keeping the gained speed.
ioctl interfaces complicate system call wrappers because there are large numbers of them, each taking different arguments, some of which may be required by normal programs.