What is the difference between an IOCTL and an IRP

Question

I have been working through some codeproject articles on driver dev, but have some confusion about IOCTLs and IRPs. From what I have seen, it seems that IOCTLs are sent from usermode, and translated into IRPs. And IRPs are messages between the OS and the device, but this doesnt seem to line up with the descriptions I am reading... leading me to think that I might be missing something.

TLDR What is the difference between an IOCTL and IRP?

Answer 1

IRPs are Windows kernel structures. They are used to represent an I/O request as it moves around the kernel system. A filesystem, for example, that needs to read from a block device generates an IRP that represents its read request and hands it to the block device. The block device processes the IRP, puts the results in the IRP, marks it complete, and tells the filesystem to look at the IRP to get the data. Devices can maintain queues of IRPs they are working on.

An IOCTL is a request to a device, typically received from a user-space application. They're generally used for requests that don't fit into a standard API. For example, you wouldn't normally use an IOCTL to open a file on a filesystem.

When a program issues an IOCTL to a device, an IRP (typically IRP_MJ_DEVICE_CONTROL) is created in kernel space to reflect that request.

In summary, an IOCTL is a particular type of "miscellaneous" request to a device driver. An IRP is a data structure for managing all kinds of requests inside the Windows driver kernel architecture.

Answer 2

IOCTL is mnemonic for IO control code, or a 32 bit value with bit fields defined within it that provides the IO manager with buffering, and other information. An IRP, or IO request packet is a structure or defined chunk of memory created by the IO manager that has all the information that the driver needs to perform a given action on an IO request, including the IOCTL. An IOCTL is used in both kernel and user mode, but an IRP is only valid within the kernel and the targeted driver or driver stack.

from user space application DeviceIoControl() -> kernel32.dll -> ntdll.dll -> the moment it gets from user mode to kernel mode -> I/O Manager -> IRP