iopl(2)

💅 iopl(2) — bestie, we gotta talk about this one

okay so this is a page from the System Calls Manual, and it's literally called iopl(2). sit down, get a snack 🍓, because the tea here is that this syscall is deprecated and we're all just being polite about it.

---

✨ NAME ✨

iopl — change I/O privilege level 👑

---

📚 LIBRARY 📚

Standard C library (that's libc, and you link it with -lc) 🫶

---

🧚 SYNOPSIS 🧚

#include <sys/io.h>

[[deprecated]] int iopl(int level);

not the [[deprecated]] right there in the prototype 💀 like, the compiler is also judging you. iconic honestly.

---

🌸 DESCRIPTION 🌸

so iopl() changes the I/O privilege level of the calling thread, and it reads that level from the two least significant bits in level. yep, just the bottom two bits. the rest of the int is vibing, ignored.

the I/O privilege level for a normal thread is 0. and permissions? inherited from parents to children. family business, iykyk 💜

now the real talk 🫖: this call is deprecated. it's significantly slower than ioperm(2), and the only reason it's still here is for older X servers that need access to all 65536 I/O ports. it's mostly for the i386 architecture. on many other architectures it literally doesn't exist, or it will always return an error. no cap. 😭

---

🎀 RETURN VALUE 🎀

• on success? zero comes back, slay ✨
• on error? -1, and errno gets set to tell you what went wrong

---

🔥 ERRORS 🔥

• EINVAL — level is greater than 3. bestie, it's a two-bit field, what did you expect 💀
• ENOSYS — this call is unimplemented. (so it just... isn't here. ghosted. 👻)
• EPERM — the calling thread doesn't have enough privilege to call iopl(); you need the CAP_SYS_RAWIO capability to raise the I/O privilege level above its current value. no permission, no party 🙈

---

🦋 VERSIONS 🦋

glibc2 has a prototype both in <sys/io.h> and in <sys/perm.h>. avoid the latter one — it's available on i386 only. choose wisely 🌈

---

⭐ STANDARDS ⭐

Linux. that's it, that's the standard. 🐧

---

👑 HISTORY 👑

grab a seat, this part is juicy:

• Prior to Linux 5.5, iopl() allowed the thread to disable interrupts while running at a higher I/O privilege level. this will probably crash the system, and it is not recommended. like... do not do this. seriously. 🚨
• Prior to Linux 3.7, on some architectures (such as i386), permissions were inherited by the child produced by fork(2) and were preserved across execve(2). that behavior was inadvertently changed in Linux 3.7, and it won't be reinstated. gone but not forgotten, I guess 💔

---

🫶 SEE ALSO 🫶

• ioperm(2)
• outb(2)
• capabilities(7)

---

okay and for the little sign-off at the end 💖 this cutie lives in Linux man-pages 6.20, dated 2026-02-08, and that's the whole iopl(2) page — deprecated but still serving looks 💅✨