includes prototypes for iopl() and ioperm(), but not all architectures provide implementations, because the implementation is conditionally compiled only if SYS_ioperm is defined. This means that on aarch64, musl is providing prototypes without implementations, which is very surprising to me. musl provides these prototypes unconditionally since commit 0004ea613ac310daaee30c167112d796db33fa70: > fix breakage from introducing bits header for sys/io.h > > apparently some other archs have sys/io.h and should not break just > because they don't have the x86 port io functions. provide a blank > bits/io.h everywhere for now. Glibc only provides on alpha, ia64, i386, x86_64, of which musl supports only the latter two. It used to provide it on arm as well, with stub implementations (ioperm() returning ENOSYS, inb returning 0, …), but the header was dropped in Glibc 2.30. Linux (as of v6.11) has an ioperm syscall on x86, microblaze, mips, and powerpc, but on everything but x86, it's just a stub that returns ENOSYS. Some code in the wild I have found expects that it can use the existence of as a proxy for being able to use inb/outb, etc. Would it make sense for musl to match the Glibc behaviour of only providing sys/io.h on i386 and x86_64? Regardless, I think that the presense of unimplemented prototypes ought to be fixed somehow.