Personal blog guide home page – click here

Original text:

Follows an explanation of the patch that introduced unlocked_ioctl and compat_ioctl into 2.6.11.
The removal of the ioctl field happened a lot later, in 2.6.36.

Explanation: When ioctl was executed, it took the Big Kernel Lock (BKL), so nothing else could
execute at the same time. This is very bad on a multiprocessor machine, so there was a big effort
to get rid of the BKL. First, unlocked_ioctl was introduced. It lets each driver writer choose
what lock to use instead. This can be difficult, so there was a period of transition during which
old drivers still worked (using ioctl) but new drivers could use the improved interface (unlocked_ioctl).
Eventually all drivers were converted and ioctl could be removed.

compat_ioctl is actually unrelated, even though it was added at the same time.
Its purpose is to allow 32-bit userland programs to make ioctl calls on a 64-bit kernel.
The meaning of the last argument to ioctl depends on the driver, so there is no way to
do a driver-independent conversion

Explanation:

IOCTL: (after 2.6.36, the field is removed). The application enters the kernel and holds a giant lock/big lock/kernel lock. At the same time, only one application enters the kernel spaceunlocked_ IOCTL: 64 is a non giant lock called by the application_ IOCTL: 32 is a non giant lock called by the application

Reference:
giant lock: giant lock – big kernel lock (BKL)
fine graded locking: non giant lock – fine graded locking
what is the difference between IOCTL unlocked IOCTL and compat IOCTL