fwiw, this came up for Android recently... we'd never had the header before but the https://blog.chromium.org/2024/06/building-faster-smarter-chromebook.html work meant we needed new x86-only stuff for the first time in a decade.

we basically went with this:

#if defined(__NR_iopl)
static __inline int ioperm(unsigned long __from, unsigned long __n, int __enabled) {
  return syscall(__NR_ioperm, __from, __n, __enabled);
}
#endif

(which answers the "some architectures" part, even though for Android that's only x86/x86-64.)

here's my commit message with more rationale for why i made them static inlines:

"""
Add <sys/io.h>.

This is unusual in being inline-only, but these are (a) trivial functions, (b) ancient functions, and (c) unusable by apps. Plus they're arriving just too late for API 35, which definitely influenced by "this is silly" decision! They're also x86/x86-64 only, though that's a neutral argument because it would mean almost no-one will be affected no matter what choice we make here.

There is an argument for going the usual "callers should just have their own header-only implementation that they `-include` on the compiler command line" route, but the x86/x86-64 I/O port stuff isn't going away just yet, and LTP was also already working around the absence of these.
"""

https://android-review.googlesource.com/c/platform/bionic/+/3135242

On Wed, Oct 30, 2024 at 5:29 AM Alyssa Ross <hi@alyssa.is> wrote:
Rich Felker <dalias@libc.org> writes:

> Can we use the remainder of this thread for figuring out the real
> status of this (what's with non-x86 archs that have the syscalls? are
> they used? what about archs that don't use them? do they have you mmap
> a device instead?) and whether there's some action that should be
> taken, rather than rehashing broad philosophy? :)

On all the other architectures where musl has SYS_ioperm defined, it's
mapped to sys_ni_syscall (ENOSYS), and has been at least since git was
introduced.

Glibc provides a fallback that uses /dev/mem on alpha, but no other
architecture.  In the past, it also provided an implementation for arm,
which was removed in the following commit:

        commit 6b33f373c7b9199e00ba5fbafd94ac9bfb4337b1
        Author: Florian Weimer <fweimer@redhat.com>
        Date:   Wed May 29 16:53:09 2019 +0200

            arm: Remove ioperm/iopl/inb/inw/inl/outb/outw/outl support

            Linux only supports the required ISA sysctls on StrongARM devices,
            which are armv4 and no longer tested during glibc development
            and probably bit-rotted by this point.  (No reported test results,
            and the last discussion of armv4 support was in the glibc 2.19
            release notes.)

The functions remain on arm, but they are just ENOSYS stubs.

Does any of that make it any clearer what should be done in musl to
solve the prototypes without implementations problem?

I guess it does make sense for musl to define __SYS_ioperm on
microblaze, mips, powerpc and powerpc64 — it's in the kernel syscall
table for those architectures, even though as far as I can tell it has
never done anything other than return ENOSYS.